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ABSTRACT 


This  report  describes  the  second  in  a  series  of  application  problems  which  are 
intended  to  measure  the  performance  of  a  process  for  rapid  prototyping  of  embedded  digi¬ 
tal  signal  processors.  The  rapid  prototyping  process  is  being  developed  for  the  ARPA/Tri- 
Services  Rapid  Prototyping  of  Application  Specific  Signal  Processors  (RASSP)  program. 
The  first  application  problem  was  to  develop  a  virtual  prototype  for  a  real-time  digital  sig¬ 
nal  processor  capable  of  forming  images  from  high-resolution  synthetic  aperture  radar 
data.  The  second  problem,  described  in  this  document,  is  to  implement  the  virtual  proto¬ 
type  in  physical  hardware  and  compare  performance  with  that  predicted  by  the  virtual  pro¬ 
totype.  Details  of  the  application  are  provided  along  with  design  constraints  and 
optimization  requirements  for  the  processor.  The  report  also  describes  product  and  process 
metrics  which  are  to  be  collected  to  derive  measures  of  process  and  product  performance. 
The  application  problem  and  associated  performance  metrics  comprise  what  is  termed  a 
Benchmark  Technical  Description. 
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1.  GENERAL 


This  document  describes  the  technical  requirements  and  deliverables  for  RASSP  Benchmark-2.  The 
main  thrust  of  Benchmark-2  is  the  development  of  prototype  hardware  and  software  for  an  embedded  pro¬ 
cessor  capable  of  forming  images  in  real  time  for  a  high  resolution  synthetic  aperture  radar  (SAR)  using 
data  from  the  Advanced  Detection  Technology  Sensor  (ADTS),  a  Ka-band  SAR  sensor  and  data  recording 
system  operated  by  MIT  Lincoln  Laboratory  [1], 

The  organization  of  this  document  parallels  that  of  the  RASSP  Benchmark- 1  Technical  Description 
(BTD-1)  [12],  which  should  be  referenced  for  background  and  detail  information.  In  this  document,  Section 
2  sets  forth  the  requirements  for  a  signal  processor  capable  of  forming  SAR  images  in  real-time  from  the 
ADTS  sensor  data.  Section  3  describes  the  data  source/sink,  which  is  to  be  used  to  exercise  and  perform 
acceptance  testing  of  the  prototype  processor.  Section  4  describes  the  metrics  which  must  be  collected  to 
evaluate  the  performance  of  the  RASSP  process  and  products  associated  with  the  development  of  the  pro¬ 
totype.  Deliverables  are  discussed  in  Section  5.  The  form  of  the  response  by  the  Developers  to  this  Bench¬ 
mark  Technical  Description  (BTD)  is  described  in  Section  6. 

1.1  INTRODUCTION  AND  OBJECTIVES 

A  component  of  the  ARPA  Rapid  Prototyping  of  Application  Specific  Signal  Processors  (RASSP) 
program  is  the  execution  of  application  benchmarks  by  the  RASSP  Developers;  i.e.,  Lockheed  Sanders,  Inc. 
and  Martin  Marietta  Corporation.  The  first  application  benchmark  was  directed  toward  the  development  of 
a  virtual  prototype  of  an  embedded  processor  for  real-time  SAR  image  formation  [12].  This  second  appli¬ 
cation  benchmark  concerns  issues  of  converting  the  virtual  prototype  of  Benchmark- 1  into  operational  hard¬ 
ware  and  software  of  a  prototype  processor. 

Benchmark- 1  concerned  the  degree  of  fidelity  and  completeness  that  could  be  obtained  for  reasonable 
cost  using  state-of-the-art  virtual  prototyping  methodologies,  models,  and  tools.  The  Developers  were 
tasked  to  develop  virtual  prototypes  using  IEEE-compliant  VHDL,  where  the  level  of  detail  and  fidelity  at¬ 
tained  in  the  virtual  prototype  was  limited  by  the  constraints  of  time  (6  months)  and  level  of  effort  (nomi¬ 
nally  5000  person-hours)  imposed  for  Benchmark- 1 .  The  Developers  were  responsible  for  establishing  cost- 
effective  methodologies  and  tools  for  the  creation  and  application  of  virtual  prototypes  to  the  development 
of  embedded  signal  processing  systems.  The  level  of  detail  for  function  and  timing  incorporated  in  the  vir¬ 
tual  prototype  was  not  to  extend  beyond  that  of  an  instmction  set  architecture  (ISA)  model  of  programmable 
devices  running  application  code  written  in  a  high-level  source  language  such  as  Ada.  The  exception  being 
that  more  detailed  models  may  have  been  required  to  validate  interface  and  timing  constraints,  but  that  such 
a  level  of  detail  would  likely  not  be  achievable  within  the  time  duration  and  level  of  effort  constraints  of 
Benchmark-1.  The  ISA  level  of  modeling  represented  a  goal  to  progress  towards  and  defined  the  limit  of 
detail  expected  in  the  VHDL  modeling.  It  did  not  prohibit  the  Developers  from  incorporating  more  detailed 
models  for  reasons  of  availability  or  risk  reduction.  However,  prior  to  developing  a  detailed  virtual  proto¬ 
type  for  a  preferred  architecture,  less  detailed  modeling  and  evaluation  of  alternative  architectures  were  per- 
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formed  to  select  the  architecture  which  best  meets  the  requirements  and  performance  goals  described  in 
BTD-1. 

This  document  establishes  the  requirements  for  development  and  delivery  of  a  prototype,  real-time 
SAR  image  processor.  The  RASSP  process  will  be  applied  to  convert  the  detailed  virtual  prototype  devel¬ 
oped  under  Benchmark- 1  into  a  physical  prototype  processor  conforming  to  the  requirements  in  BTD-1  as 
amended  in  this  document.  In  this  benchmark,  three  processor  implementations  should  be  examined  for 
cost.  One  version  would  provide  up  to  three  polarizations  of  output  image  data,  the  second  version  would 
provide  only  one  output  polarization,  and  the  third  version  would  provide  as  much  functionality  as  possible 
for  a  total  cost  of  less  than  $500K  for  the  benchmark.  If  the  single  or  triple  polarization  options  cost  less 
than  $500K,  the  option  for  “maximum  functionality  for  less  than  $500K”  may  be  dropped.  In  all  cases,  the 
polarization  of  the  output  data  must  be  selectable  from  among  the  four  polarizations  of  input  data  and  the 
design  hardware  must  be  fabricated  within  the  six-month  benchmark  cycle.  Therefore,  the  designs  are  con¬ 
strained  to  be  producable  in  unit  quantities  over  a  period  of  nominally  six  months,  and  for  a  total  equivalent 
cost  (normalized  to  person  hours)  of  between  5000  to  10,000  person  hours.  This  BTD  includes  size,  weight, 
and  power  constraints  consistent  with  use  of  the  processor  on  board  a  small  unmanned  air  vehicle  (UAV); 
see  [12].  The  resulting  processor  will  have  a  form  factor  consistent  with  a  UAV,  but  will  be  compatible  with 
the  sensor  flown  on  board  the  ADTS  Gulfstream  aircraft. 

1.2  ADTS  DATA  FORMAT 

The  ADTS  system  consists  of  an  integrated  radar,  navigation,  and  recording  system  carried  on  board 
a  Gulfstream  twin-engine  aircraft  [  1  ] .  An  overview  of  the  ADTS  aircraft  and  sensor  are  given  in  BDT- 1  [  1 2]. 
To  develop  a  processor  for  real-time  SAR  image  formation  from  the  ADTS  sensor  data,  information  about 
data  formats  is  required.  The  intent  is  to  interface  the  real-time  SAR  image  processor  directly  to  the  ADTS 
system  without  modifying  the  existing  data  formats  or  timing  of  the  ADTS  system. 

Figure  1  illustrates  the  organization  of  the  data  within  the  40-bit  data  word  as  it  is  presented  to  the 
parallel-to-serial  converter  for  transmission  over  the  fiber-optic  link.  The  1 1-bit  samples  are  right-justified 
in  twos-complement  representation  and  are  sign  extended  in  a  12  bit  field.  There  are  2032  even/odd  data 
pairs  comprising  a  pulse  repetition  interval  (PRI),  and  four  transmit-receive  polarization  pairs  for  each  PRI. 

1.2.1  PRI  Preamble 

Each  PRI  of  data  is  preceded  by  a  code  or  preamble  which  is  duplicated  in  bits  3  through  16,  19  and 
32  of  the  40-bit  data  word.  This  preamble  consists  of  a  prefix  of  5  leading  zeros,  followed  by  a  13-bit  Barker 
code,  followed  by  a  suffix  of  2  trailing  don’t-care  words.  The  Barker  code  values,  along  with  the  zero  prefix 
and  don’t-care  suffix,  are  indicated  in  Table  1. 
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39:33 

32 

31:20 

19 

18:17 

16 

15:04 

03 

02:00 

0 

NOT 

0 

0 

5  ZERO  WORDS 

0 

B 

USED 

B 

B 

13  BARKER  WORDS 

B 

F 

F 

F 

2  FILLER  WORDS 

F 

H 

ODD  HH  SAMPLES 

2032  WORDS 

H 

H 

EVEN  HH  SAMPLES 

2032  WORDS 

H 

A 

A 

A 

A 

F 

VARIABLE  FILLER  WORDS 

F 

F 

VARIABLE  FILLER  WORDS 

F 

0 

NOT 

0 

0 

5  ZERO  WORDS 

0 

B 

USED 

B 

B 

13  BARKER  WORDS 

B 

F 

F 

F 

2  FILLER  WORDS 

F 

H 

2032  ODD  HV  WORDS 

H 

H 

2032  EVEN  HV  WORDS 

H 

F 

VARIABLE  FILLER  WORDS 

F 

F 

VARIABLE  FILLER  WORDS 

F 

0 

NOT 

0 

0 

5  ZERO  WORDS 

0 

B 

USED 

B 

B 

13  BARKER  WORDS 

B 

F 

F 

F 

2  FILLER  WORDS 

F 

H 

2032  ODD  VH  WORDS 

H 

H 

2032  EVEN  VH  WORDS 

H 

F 

VARIABLE  FILLER  WORDS 

F 

F 

VARIABLE  FILLER  WORDS 

F 

0 

NOT 

0 

0 

5  ZERO  WORDS 

0 

B 

USED 

B 

B 

13  BARKER  WORDS 

B 

F 

F 

F 

2  FILLER  WORDS 

F 

H 

2032  ODD  VV  WORDS 

H 

H 

2032  EVEN  VV  WORDS 

H 

F 

VARIABLE  FILLER  WORDS 

F 

F 

VARIABLE  FILLER  WORDS 

F 

0  -  ZERO  BITS 
B  -  BARKER  BITS 
H  -  HEADER  BITS 
A-AUXBITS 
F  -  FILLER  BITS 

Figure  I.  Format  of  the  40-bit  wide  ADTS  data. 
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TABLE  1 


Bit  Pattern  for  PRI  Preamble 


Run 

Length 

Bits  3-16, 

19,  32 

5 

0 

3 

1 

1 

0 

1 

1 

2 

0 

1 

1 

3 

0 

2 

1 

2 

X 

The  sole  function  of  the  preamble  is  to  indicate  that  a  PRI  of  radar  data  follows.  The  use  of  a  Barker 
code  in  the  preamble  does  not  relate  in  any  way  to  any  modulation  applied  to  the  radar  waveform. 

Bit  16  of  the  40-bit  input  data  word  contains  two  types  of  information  in  bit-serial  format.  The  infor¬ 
mation  always  starts  with  the  HH  PRI  of  the  data,  and  fits  entirely  within  the  HH  dataset. 

•  A  16  bit  header  word  for  each  PRI  identifying  the  transmit-receive  polarization.  The 
header  word  is  recorded  with  the  MSB  as  the  first  of  16  bits. 

•  Aux  data  consisting  of  57  16-bit  words  with  the  MSB  again  recorded  as  the  first  bit  for 
each  word.  The  Aux  data  follows  immediately  after  the  header  word. 

This  same  bit-serial  information  is  repeated  in  bit  locations  3,  19,  and  32  of  the  40-bit  input  data  word. 
1.2.2  Bit-Serial  Aux  Data 

Figure  2  defines  the  contents  of  the  Aux  record  and  the  associated  units.  For  the  Aux  variables  that 
are  written  over  two  16-bit  words,  the  MSBs  are  contained  in  the  first  word. 
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WORDS 

LSB 

DEFINITION 

COMMENTS 

PNINS 

2 

r‘^m 

INS  North  Position 

MSB  of  Word  2  is  0 

PEINS 

2 

T'‘'m 

INS  East  Position 

MSB  of  Word  2  is  0 

PDINS 

I 

2  m 

INS  Down  Position 

VNINS 

1 

2'^  m/s 

Level  North  Velocity 

VEINS 

1 

2'^  m/s 

Level  East  Velocity 

PNMS 

2 

r'^m 

Motion  Sensed  North  Pos. 

MSB  of  Word  2  is  0 

PEMS 

2 

Motion  Sensed  East  Pos. 

MSB  of  Word  2  is  0 

PDMS 

2 

r'^m 

Motion  Sensed  Down  Pos. 

MSB  of  Word  2  is  0 

VNMS 

2 

2'^^  m/s 

Motion  Sensed  North  Vel. 

MSB  of  Word  2  is  0 

VEMS 

2 

m/s 

Motion  Sensed  East  Vel. 

MS  B  of  Word  2  is  0 

VDMS 

2 

m/s 

Motion  Sensed  Down  Vel. 

MSB  of  Word  2  is  0 

TRGN 

2 

Aimpoint  North  Pos. 

MSB  of  Word  2  is  0 

TRGE 

2 

r'-'m 

Aimpoint  East  Pos. 

MSB  of  Word  2  is  0 

TRGD 

2 

2-'’m 

Aimpoint  Down  Pos. 

MSB  of  Word  2  is  0 

TENSEC 

1 

2^  sec 

Time  Word#  I 

Time  =  10  x  TENSEC  +  MILSEC  / 
1000 

MILSEC 

I 

2^  msec 

Time  Word  #2 

SLTRNG 

2 

r‘^m 

Range  to  Aimpoint 

MSB  of  Word  2  is  0 

RNGDOT 

2 

m/s 

Velocity  Toward  Aimpoint 

MSB  of  Word  2  is  0 

ANTYAW 

1 

2‘^rad 

Antenna  Yaw  Command 

ANTPIT 

1 

2'‘^  rad 

Antenna  Pitch  Command 

ANTROL 

' 

2''^  rad 

Antenna  Roll  Command 

ANTSTA 

I 

Antenna  Status  Flag 

SCNPOS 

I 

2^  steps 

Scanner  Position 

8192  steps  =  360^^ 

RAW  7 

' 

2* 

Range  to  DME7 

NI 

1 

2' 

N2 

I 

2^ 

CNAVER 

2 

Avg.  North  Update  for  INS 

MSB  of  Word  2  is  0 

CEAVER 

2 

2-‘^m 

Avg.  East  Update  for  INS 

MSB  of  Word  2  is  0 

WMC 

I 

2^  Hz 

MoComp  Freq.  Coef. 

PHSMC 

1 

2' ‘^cycles 

MoComp  Phase  Coef. 

RAl 

1 

2'* 

Azm.  Prefilter  Coef. 

HDGINS 

1 

2'^^  7C  rads 

Heading  Angle 

PCHINS 

1 

2'^^  7t  rads 

Pitch  Angle 

ROLINS 

1 

r‘^  71  rads 

Roll  Angle 

MODE 

1 

Radar  Mode 

CMPTME 

1 

2^  ms 

Time  in  msec 

IMUVX 

1 

2-i4 

IMU  X  velocity 

units  of  .3048  m/s 

IMUVY 

1 

2-14 

IMU  y  velocity 

units  of  .3048  m/s 

IMUVZ 

1 

IMU  z  velocity 

units  of  .3048  m/s 

IMUTHX 

I 

1 

IMUTHY 

1 

rad/s 

IMU  Neg.  Roll  Ang.  Rate 

IMUTHZ 

1 

2'^^  rad/s 

IMU  Neg.  Pitch  Ang.  Rate 

Figure  2.  Aux  record  format  and  units. 
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1.2,3  Header  Word 

The  header  word  is  used  to  signify  the  transmit-receive  polarization  of  the  associated  PRI  of  data.  The 
four  types  of  polarization  and  their  associated  header  designations  are  given  in  Table  2. 


TABLE  2 

Polarization  and  Hexadecimal  Header  Designations 


2.  PROCESSOR  REQUIREMENTS 


This  section  describes  the  complete  requirements  for  a  real-time,  multiple  polarization  SAR  proces¬ 
sor.  For  Benchmark  2,  processor  development  will  be  carried  from  the  virtual  prototype  developed  in 
Benchmark- 1  to  a  prototype  ranning  in  real  time  and  interfaced  with  data  source/sink  (Section  3). 

2.1  IMAGE  FORMATION 

During  operation,  the  SAR  processor  continuously  forms  images  for  up  to  three  of  the  four  input  po¬ 
larizations  (Figure  1 ).  Figure  2  illustrates  the  processing  flow.  In  addition  to  the  continuous  process  of  image 
formation,  there  is  a  setup  process  which  occurs  before  the  first  frame  of  data.  The  setup  process  is  described 
in  more  detail  in  Section  2.2.2. 

2.1.1  Accuracy 

The  SAR  processor  should  be  capable  of  supporting  full-scale  input  signals  without  saturation,  and 
quantization  errors  in  the  output  data  should  be  10  dB  below  receiver  noise.  A  full-scale  input  signal  has  an 
amplitude  of  approximately  2^°  relative  to  the  input  LSB  of  2®  and  receiver  noise  at  the  input  is  nominally 
set  at  the  bit.  As  a  result,  the  peak  output  SNR  is  1 .979  x  10  ,  or  93  dB,  and  the  minimum  dynamic  range 
of  the  SAR  processor  is  required  to  be  103  dB.  Lincoln  Laboratory  has  a  non  real-time  implementation  of 
the  image  formation  algorithm  which  executes  on  a  workstation.  The  images  formed  using  this  implemen¬ 
tation  are  output  in  32-bit  IEEE  floating  point  and  represent  the  basis  for  acceptance  testing  of  the  SAR  pro¬ 
cessor. 

To  verify  that  adequate  processor  dynamic  range  and  accuracy  are  achieved,  differences  between  cor¬ 
responding  pixels  in  a  processed  SAR  image,  ,  and  the  Lincoln  Laboratory  reference  SAR  image, 
^REF'  ^  calculated.  If  and  are  complex  pixel  values  from  corresponding  processed  and 
reference  SAR  images,  the  power  of  the  error  due  to  processing,  ,  is  given  by 

I  _  1^ 

D  _  1^5/1/?  ^REf\ 

^ERR  2  ’ 

where  the  processing  error  in  both  the  processed  and  reference  imagery  are  equal.  A  processor  dynamic 
range  of  103  dB  means  that  the  Pppp  should  be  less  than  —103  dB  relative  to  the  maximum  output  signal 
power,  or 
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Figure  3.  SAR  image  processing  flow. 
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where  is  the  maximum  pixel  power  of  1 .4736  x  10  .  The  SAR  processor  will  be  tested  using  both 

actual  radar  data  and  synthesized  test  data,  with  representative  data  sets  supplied  by  Lincoln  Laboratory  in 
the  tape  media  format  discussed  in  Section  2.6.2. 

2.1.2  PRI  Detection 

As  previously  discussed,  channels  of  polarized  pulse  data,  header  data,  and  Aux  data  are  presented  to 
the  RASSP  processor.  A  20-word  sequence  consisting  of  a  13-word  Barker  code  with  5  leading  zeros  and  2 
trailing  don’t-care  words  indicates  the  start  of  pulse  data.  This  preamble  is  followed  by  2032  words  of  11- 
bit  even  pulse  samples  and  11 -bit  odd  pulse  samples  in  twos-complement  representation  and  are  sign  ex¬ 
tended  to  1 2  bits.  Included  with  the  pulse  samples  are  header  data  and  Aux  data  recorded  in  bit-serial  fashion 
and  duplicated  in  bit  positions  3,16,19,  and  32  of  the  40-bit  data  word.  Header  data  describes  the  polariza¬ 
tion  of  the  pulse  data,  and  Aux  data  contains  ancillary  navigation  and  radar  data.  Pulse  data  for  the  four  po¬ 
larizations  are  output  in  a  repeated  sequence  (i.e.,  ...  ,  HH,  HV,  VH,  VV,  HH,  ...  ),  but  Aux  data  are  only 
written  for  the  leading  pulse  of  the  sequence  (i.e.,  HH).  There  are  filler  data  between  the  end  of  data  for  one 
pulse  and  the  start  sequence  for  the  next  pulse.  PRI  data  are  written  at  a  4.56  MW/s  rate.  The  maximum 
radar  PRF  is  556  Hz  and  the  minimum  PRF  is  200  Hz. 

Because  the  HV  and  VH  polarizations  contain  the  same  information,  no  more  than  three  of  the  four 
polarizations  are  used  to  form  images.  Generally,  images  will  be  formed  for  the  HH  and  VV  polarizations, 
and  either  the  HV  or  the  VH  polarization  as  established  through  the  RS-232  control  interface  by  the  opera¬ 
tor.  It  is  therefore  necessary  to  process  and  retain  pulse  polarization  information  from  the  header.  In  addi¬ 
tion,  Aux  data  must  be  processed  to  extract  slant  range  data  for  each  pulse  (SLTRNG). 

2.1.3  Video  to  Baseband  I/Q  Conversion 

Prior  to  pulse  compression,  4064  real  video  samples  of  each  of  the  three  polarizations  to  be  imaged 
must  be  converted  to  complex  (in-phase  and  quadrature,  or  I/Q)  data  at  baseband.  The  baseline  approach  for 
performing  the  I/Q  demodulation  is  to  form  sequences  of  even  and  odd  pulse  samples  and  modulate  each 
sequence  by  (-1)".  This  yields  two  real- valued  sequences  for  each  pulse:  an  even  sample  sequence,  {sq,  -S2, 
S4,  -S5, ... ,  -S4052}>  and  an  odd  sample  sequence  (sj,  -S3,  S5,  -S7, ... ,  -  S4063},  where  s^  is  the  n***  real  sample. 
Each  sequence  is  then  passed  through  an  FIR  filter  with  up  to  48  coefficients.  Currently,  the  even  sequence 
is  passed  through  an  8-coefficient  FIR  filter  to  yield  the  sequence  (sjo,  Sjj,  Si2, ...  ,  512023}-  The  FIR  filter 
output  sequence  is  8  samples  shorter  than  the  FIR  input  sequence  because  the  filter  must  be  initialized  before 
valid  data  samples  are  obtained.  Similarly,  the  odd  sequence  is  passed  through  an  8-coefficient  FIR  filter  to 
yield  the  sequence  {SqQ,  Sqj,  Sq2, ... ,  Sq2023}.  These  sequences  are  combined  to  form  the  sequence  of  com¬ 
plex  samples  {(Sio,Sqo),  (Sjj,  Sqj), ... ,  (Si2023>  ®q2023)}-  The  baseline  coefficients  for  the  FIR  filters  are  given 
in  Table  3.  The  current  implementation  of  the  FIR  filter  is  given  by. 
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y  =  \  a  X  , 

•'n  ^  m  n+m 

m-0 

where  is  the  n*  output  sample,  is  the  n***  input  sample,  and  a^,  is  the  FIR  coefficient. 


TABLE  3 

Baseline  l/Q  Filter  Coefficients 


Index 

Even  Sequence 

Odd  Sequence 

0 

-0.021133 

0.019827 

1 

0.055895 

-0.011912 

2 

-0.148449 

-0.067483 

3 

0.406139 

0.917516 

4 

0.917516 

0.406139 

5 

-0.067483 

-0.148449 

6 

-0.011912 

0.055895 

7 

0.019827 

-0.021133 

2,1.4  Range  Compression 

In  pulse  compression,  the  2024  (uncompressed)  I/Q  samples  of  each  pulse  are  transformed  into  a 
(compressed)  range  pulse  with  2048  samples.  Each  of  the  2048  samples  can  be  thought  of  as  constituting  a 
range-gate.  The  first  step  in  pulse  compression  is  the  application  of  equalization  weighting  to  the  complex 
valued  I/Q  data.  This  weighting  reduces  the  sidelobes  of  the  compressed  pulse,  centers  the  compressed  pulse 
in  the  range  window,  and  compensates  for  non-ideal  IF  filter  characteristics  that  degrade  image  resolution. 
The  weighting  is  applied  to  the  2024  complex  input  samples  with  trailing  zero-pads  to  expand  the  data  to 
2048  samples.  The  equalization  weights  are  down-loaded  to  the  S  AR  processor  prior  to  real-time  operation 
via  the  control  interface.  The  weights  are  polarization  specific  so  that  polarization  data  extracted  from  the 
data  header  must  be  used  in  establishing  which  set  of  equalization  weights  to  apply  to  a  given  set  of  data. 

Weighted  I/Q  data  are  transformed  to  (compressed)  range  data  using  a  2048  point  DFT.  The  resulting 
sample  interval  in  range  is  0.2287  meters.  In  some  cases  it  is  necessary  to  compensate  for  elevation  beam- 
shape  modulation  of  the  radar  cross  section  (RCS)  across  the  range  swath,  as  well  as  effects  of  R'^  variations 
in  RCS  over  the  range  swath.  To  compensate  for  these  RCS  variations,  amplitude  weights  are  applied  to 
samples  of  the  compressed  pulse.  The  RCS  weights  are  down-loaded  to  the  SAR  processor  prior  to  real¬ 
time  operation  via  the  control  interface. 
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2.1.5  Azimuth  Compression 

Azimuth  compression  is  performed  using  the  process  of  cross-range  convolution  filtering.  Com¬ 
pressed  pulses  are  placed,  in  time  sequence,  into  a  2-D  processing  array  and  each  row  of  the  array  is  con¬ 
volved  with  a  row-specific  reference  kernel.  The  convolution  outputs  are  saved  in  an  image  array  which 
becomes  the  output  stripmap  image  of  the  SAR. 

In  this  process,  compressed  pulses  are  placed  in  time  sequence  in  a  2-D  array  referred  to  as  a  frame. 
Each  row  of  the  frame  conteiins  512  pulses  and  each  column  contains  2048  range  gates,  so  that  each  frame 
is  a  2048  x  512  array.  Once  512  pulses  have  been  accumulated  to  form  a  frame,  the  frame  is  shifted  into 
the  processing  array.  The  processing  array  is  a  2-D  array  where  azimuth  compression  processing  is  per¬ 
formed.  The  processing  array  consists  of  two  frames;  i.e.,  the  processing  array  is  2048  x  1024 .  As  each  new 
frame  is  shifted  into  the  processing  array,  the  oldest  frame  is  shifted  out.  A  convolution  is  performed  along 
each  row  of  the  processing  array,  where  the  convolution  kernel  is  the  approximate  response  of  a  point  scat- 
terer  located  at  the  range-gate  of  the  row,  as  described  in  Appendix  A.’ 

Figure  4  depicts  convolution  processing  for  one  row  of  the  processing  array.  Convolution  processing 
is  currently  performed  using  DFTs  with  the  overlap-save  method.  The  processing  array  consists  of  1024 
pulses,  with  2048  complex  range  samples  each.  The  convolution  kernels  (see  Appendix  A)  are  512  points 
long,  but  trailing  zeros  are  used  to  pad-out  the  kernel  to  1024  points.  A  1024-point  DFT  of  each  row  is  mul¬ 
tiplied  with  the  1024-point  DFT  of  the  associated  convolution  kernel.  Each  vector  product  is  inverse  trans¬ 
formed,  and  the  last  512  samples  of  each  inverse  transform  represent  valid  convolution  outputs  and  are 
saved  in  an  image  array.  A  new  frame  is  then  shifted  into  the  processing  array,  the  convolution  process  is 
repeated,  and  more  data  are  added  to  the  image  array  thereby  generating  the  output  stripmap  SAR  image. 

The  convolution  kernel  used  for  each  row  is  selected  from  a  database  of  3 1  pre-calculated  kernels, 
where  the  kernels  have  been  Taylor  weighted,  zero  padded,  and  Fourier  transformed  (i.e.,  the  processor  does 
not  transform  the  kernels).  The  choice  of  kernel  is  determined  by  the  slant  range  to  the  middle  of  the  most 
recent  frame  in  the  processing  array.  This  slant  range  is  given  by  SLTRNG  in  the  Aux  record  of  the  256* 
pulse  of  the  most  recent  frame.  The  kernels  are  calculated  based  on  the  slant  range  (SLTRNG)  to  the  middle 
of  the  first  frame  of  data  obtained  for  a  given  pass,  and  are  stored  for  use  throughout  the  pass.  Only  1 6  of 
the  3 1  stored  kernels  are  used  at  one  time  in  azimuth  compression,  but  these  1 6  vary  with  each  frame.  A 
more  detailed  discussion  of  the  kernel  calculation  and  selection  process  is  given  in  Appendix  A. 

2.1.6  Latency 

The  latency  between  a  frame  of  data  being  input  to  the  SAR  processor  and  the  corresponding  image 
being  output  from  the  processor  shall  not  exceed  3  seconds.  A  frame  is  considered  to  be  input  to  the  proces¬ 
sor  when  the  last  pulse  used  to  form  the  frame  is  passed  to  the  SAR  processor.  A  frame  is  output  when  the 


1.  The  descriptions  of  Appendix  A  reflect  input  from  Lockheed  Sanders  [13]. 
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first  image  pixel  from  the  corresponding  frame  is  passed  out  of  the  processor.  Figure  4  depicts  the  relation¬ 
ship  between  input  frames  of  data  and  corresponding  output  frames  of  images. 


NEAR  RANGE 


FAR  RANGE 


KERNEL 


EARLIEST  LATEST 


X  VECTOR  MUTLIPLY 


TO  IMAGE  ARRAY 


Figure  4.  Cross-range  convolution  processing. 


2.2  EXTERNAL  INTERFACES 


2.2.1  Fiber  Optic  Interfaces 

The  data  stream  to  and  from  the  SAR  processor  will  be  bit  serial  over  fiber-optic  links,  compatible 
with  TriQuint’s  HRC-500FS  module.  A  data  sheet  describing  the  HRC-500FS,  which  is  based  on  the  Hot 
Rod™  chip  set,  is  given  in  Appendix  A.  Use  of  the  TriQuint  Hot  Rod  chip  or  transmit-receive  module,  in 
the  signal  processor  is  recommended,  but  any  implementation  of  the  interface  compatible  with  the  HRC- 
500FS,  configured  as  described  in  this  section,  is  acceptable.  The  description  in  the  remainder  of  this  section 
will  assume  that  an  HRC-500FS  is  used.  To  facilitate  loop-back  testing,  the  same  data  rate  settings  will  be 
used  for  input  and  output  data  transfers.  It  will  be  shown  subsequently  that  the  HRC-500FS  provides  a  link 
with  excess  capacity. 

The  data  rate  for  the  HRC-500FS  will  be  derived  from  a  reference  clock  of  25  MHz.  DIV 1,  DIVO  will 
be  set  to  1, 0  respectively — corresponding  to  a  data  rate  of  12.5  Mwords/s,  500  Mbps  and  625  Mbaud  (the 
link  uses  4B/5B  encoding).  When  the  HRC-500FS  is  operated  at  90%  of  maximum  capacity  or  less,  a  sim¬ 
plified  interface  design  with  free-running  data  strobe  is  possible.  This  approach  will  be  used  for  the  SAR 
application,  and  provides  an  11.25  MW/sec  transfer  rate  capability  which  is  suitably  in  excess  of  system 
requirements. 

The  transmission  medium  is  a  heavy-duty  multi-mode  50/125  fiber  optic  cable  with  FSMA  connec¬ 
tors.  This  cable  runs  to  a  bulkhead  feedthrough  (e.g.,  AMP  #504020-2)  on  the  SAR  processor  chassis,  then 
through  an  adapter  cable  (e.g.,  Powell  Electronics  #907-99999-00264)  to  the  HRC-500FS. 

2.2.1.1  Sensor  Input  Data.  Referring  to  Figure  5,  the  input  data  fields  of  interest  and  their  corre¬ 
sponding  bit  assignments  on  the  HRC-500FS  are  summarized  in  Table  4.  Bits  0-2, 17-18  and  33-39  are  pres¬ 
ently  unused  and  will  always  be  zero.  As  described  in  Section  2. 1 .2,  data  are  available  to  the  signal  processor 
as  40-bit  words  at  a  rate  of  4.56  MW/s,  which  is  well  within  the  limitations  imposed  by  the  HRC-500FS. 

There  will  also  be  extra  (unused  and  meaningless)  data  words  at  the  end  of  each  PRI.  The  total  number 
of  these  extra  words  'will  depend  on  the  speed  of  the  platform,  which  affects  the  spatial  sampling  rate  or  PRF. 
The  PRI  preamble  should  always  be  used  to  identify  the  beginning  of  a  block,  and  a  count  of  the  number  of 
input  samples  should  be  used  to  determine  when  the  end  of  a  PRI  data  block  has  been  reached.  A  PRI  will 
always  consist  of  2032  valid  40-bit  data  words,  followed  by  a  variable  number  of  meaningless  words. 

2.2.1.2  Processed  Output  Data.  Processed  image  data  will  be  output  in  the  full  precision  of  the 
SAR  processor  hardware,  up  to,  but  not  exceeding,  32-bit  floating  point.  If  the  chosen  format  uses  less  than 
32  bits,  the  bits  used  will  be  justified  into  the  LSBs  so  that  the  unused  bits  are  the  MSBs.  TFFE  single-pre¬ 
cision  floating  point  format  is  preferred. 
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TABLE  4 

Input  Bit/Pin  Assignments 


Bits 

Pins 

Description 

02:00 

RxD02 :  RxDOO 

Not  used,  always  zero 

03 

RxD03 

Aux  Serial 

15:04 

RxD15:RxD04 

Even  Sample 

16 

RxD16 

Aux  Serial 

18  : 17 

RxD18:RxD17 

Not  used,  always  zero 

19 

RxD19 

Aux  Serial 

31  : 20 

RxD31  :  RxD20 

Odd  Sample 

32 

RxD32 

Aux  Serial 

39:33 

RxD39 :  RxD33 

Not  used,  always  zero 

The  output  data  format  for  each  polarization  processed  will  consist  of  an  image  frame  header  fol¬ 
lowed  by  the  complex  samples  from  each  image.  There  will  be  a  maximum  of  three  polarizations  imaged 
per  frame.  The  complex  samples,  corresponding  to  image  pixels,  will  be  output  in  azimuth  order  (i.e.,  in 
order  of  increasing  time)  beginning  at  the  near  range  and  finishing  at  the  far  range.  The  output  data  format 
is  shown  in  Figure  5.  The  frame  header  will  be  constructed  as  shown  in  Figure  5  with  the  format  as  shown 
in  Table  5. 

The  zero  prefix  and  Barker  code  will  be  implemented  across  the  32  LSBs  of  the  parallel  output  word. 
The  polarization  code  for  the  image  will  be  specified  according  to  the  code  in  Table  2.  Each  two-byte  code 
defining  the  polarization  will  be  embedded  in  the  16  LSBs  of  a  40-bit  output  word,  and  repeated  in  the  16 
contiguous  bits.  The  57  Aux  data  words  output  with  each  frame  will  be  those  associated  with  the  256*  pulse 
of  the  most  recent  frame  in  the  processing  array,  as  discussed  in  Section  2.1.5.  Each  two-byte  Aux  data  word 
will  be  embedded  in  the  16  LSBs  of  a  40-bit  output  word  and  repeated.  Each  complex  image  sample  will 
be  output  as  a  real  sample  embedded  in  a  32-bit  output  word  followed  by  an  imaginary  sample  embedded 
in  a  32-bit  output  word.  The  LSB  of  the  image  samples  is  bit  00.  The  total  number  of  bits  in  an  output  word 
required  to  represent  a  real  or  imaginary  sample  will  depend  upon  the  number  representation  used  in  the 
SAR  processor  hardware,  but  must  not  exceed  32.  If  the  output  words  are  less  than  32  bits  they  should  be 
right  justified  in  the  bit  31 :00  field  (the  MSBs  will  be  the  unused  ones). 

The  output  bits  39:40  are  used  for  a  2-bit  polarization  code,  as  shown  in  Table  5.  This  2-bit  code  is  in 
addition  to  the  16-bit  code  in  bits  31:16  and  15:00  of  output  frame  word  21.  This  2-bit  code  is  present  with 
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39:38 

37:32 

31:16 

15:00 

5  WORDS  OF  LEADING  ZEROS 

2 

13  WORD  BARKER  CODE 

B 

1 

T 

2  WORDS  OF  FILLER 

POLARIZATION  CODE 

REPEATED  POL  CODE 

1 

AUX  WORD  1 

REPEATED  AUX  WORD  1 

P 

0 

L 

• 

• 

• 

• 

• 

A 

R 

AUX  WORD  57 

REPEATED  AUX  WORD  57 

1 

Z 

1  PIXEL  VALUE;  RANGE  0,  AZIMUTH  0 

A 

T 

Q  PIXEL  VALUE;  RANGE  0,  AZIMUTH  0 

1 

1 

0 

N 

• 

• 

• 

1  PIXEL  VALUE;  RANGE  0,  AZIMUTH  511 

Q  PIXEL  VALUE;  RANGE  0,  AZIMUTH  511 

1  PIXEL  VALUE;  RANGE  1,  AZIMUTH  0 

Q  PIXEL  VALUE;  RANGE  1,  AZIMUTH  0 

• 

• 

• 

1  PIXEL  VALUE;  RANGE  2047,  AZIMUTH  511 

Q  PIXEL  VALUE;  RANGE  2047,  AZIMUTH  511 

Figure  5.  Format  of  the  40-bit  wide  output  dntr, 
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TABLE  5 

Format  of  the  40-bit  Wide  Output  Data 


Word  No. 

Bits 

Pins 

Contents 

1  -5 

31  :00 

TxD31  :  TxDOO 

Prefix  of  Zeros 

6-18 

31  :00 

TxD31  :  TxDOO 

Barker  Code 

19-20 

31  :00 

TxD31  :  TxDOO 

Suffix  (don’t  care) 

21 

15:00 

TxD15  :TxD00 

Polarization  Code 

21 

31  : 16 

TxD31  :TxD16 

Polarization  Code 

22-78 

15:00 

TxD15:TxD00 

Aux  Data 

22-78 

31  : 16 

TxD31  :TxD16 

Aux  Data 

79  -  2,097,230 

31  :00 

TxD31  :  TxDOO 

Complex  Image  containing  512  x  2048  pixels 

1  -  2,097,230 

39:38 

TxD39 :  TxD38 

2-bit  polarization  code:  0->HH,  1-^HV,  2— >VH,  3-^VV 

every  output  word.  It  is  expected  that  this  will  be  implemented  by  having  a  2-bit  output  register.  The  data 
can  be  output  in  bursts  with  the  contents  of  the  2-bit  register  being  changed  between  bursts. 

At  the  maximum  PRF  of  556  Hz,  the  5 12  pulses  needed  to  form  an  image  frame  are  collected  in  slight¬ 
ly  more  than  .92  s.  If  three  images,  corresponding  to  three  different  polarizations,  are  output  at  this  same 
rate,  then  the  output  interface  must  support  an  average  transfer  rate  of  slightly  more  than  6.83  MW/s  or 
equivalently  27  32  MB/s  (34.15  MB/s  including  the  unused  byte  of  the  40-bit  word),  which  represents  the 
maximum  average  output  rate.  Thus,  the  input  rate  (4.56  MW/s)  and  output  rate  (6.83  MW/s)  are  well  within 
the  11.25  MW/s  link  capacity.  The  output  data  may  be  output  in  bursts  at  any  rate  between  the  mmmum  of 
27.32  MB/s  and  a  maximum  of  32  MB/s.  The  upper  limit  on  output  burst  rate  of  32  MB/s  (8  MW/s)  is  im¬ 
posed  by  the  maximum  speed  of  the  logic  in  the  data  sink  and  not  by  the  fiber  optic  link. 

2.2,2  Control  and  Diagnostic 

The  control  interface  is  bidirectional  RS-232.  The  baud  rate  will  preselectable.  At  a  minium  the  choic¬ 
es  will  include  9.6  Kbaud  and  19.2  Kbaud.  It  is  desirable  that  the  interface  also  support  38.4  Kbaud.  Hard¬ 
ware  handshaking  will  be  used,  and  the  interface  will  support  the  transfer  of  8-bit  binary  data— although 
initially  we  do  not  plan  to  transfer  binary  data. 

The  RS-232  connection  on  the  SAR  processor  will  be  configured  in  the  same  fashion  as  data  commu¬ 
nications  equipment.  Consequently,  it  will  likely  be  possible  to  connect  directly  (with  no  pin  swaps)  to  the 
modem  output  of  a  workstation  or  personal  computer.  The  connector  will  be  male,  and  the  pin  assignments 
will  be  made  as  indicated  in  Table  6. 

The  control  and  diagnostic  interface  is  intended  to  serve  a  variety  of  purposes.  The  minimum  set  of 
control  and  diagnostic  commands  which  must  be  supported  are  listed  in  Table  7.  Additional  commands  may 
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TABLE  6 

Control  and  Diagnostic  Pin  Assignments 


Direction* 

Pin 

Signal 

Function 

B 

1 

FG 

Frame  ground 

T 

2 

TD 

Data  to  processor 

F 

3 

RD 

Data  from  processor 

T 

4 

RTS 

Flow  control  -  OK  for  processor  to  send 

F 

5 

CTS 

Flow  control  -  processor  is  ready  for  data 

F 

6 

DSR 

Always  true 

B 

7 

SG 

Signal  ground 

F 

8 

DCD 

Always  true 

T 

20 

DTR 

Not  used 

*  Direction  denotes  the  data  flow  to  and  from  the  processor;  T  -  into,  F  -  from, 

B  -  bidirectional. 

be  added  at  the  discretion  of  the  developer  as  an  aid  in  diagnosing  and  debugging  the  system  during  devel¬ 
opment. 

The  interface  is  intended  to  allow  a  person  to  sit  at  a  terminal  and  enter  the  commands,  although  it 
may  not  be  practical  for  a  person  to  type  in  the  data  sets  required  by  some  commands.  Also,  an  external  com¬ 
puter  should  be  able  to  “drive”  the  SAR  processor  using  this  same  interface.  To  this  end,  all  of  the  com¬ 
mands  in  Table  7  and  data  for  those  commands  will  be  in  ASCII.  Commands  will  be  entered  as  the  strings 
given  in  Table  7  terminated  by  a  CR  (carriage  return).  The  commands  wUl  not  be  case  sensitive.  Backspace 
characters  (control-H)  will  delete  the  most  recent  characters  entered.  Each  line  will  be  terminated  by  a  CR. 
For  those  commands  that  require  data,  an  EOF  (end  of  file,  indicated  by  a  control-D)  after  the  CR  for  the 
last  line  will  indicate  the  end  of  the  numerical  input  for  a  command.  If  an  incorrect  number  of  values  is  input, 
an  error  message  will  result. 

The  types  of  numerical  input  for  each  command  are  given  in  Table  7.  Integers  will  be  entered  as  dec¬ 
imal  integers.  Real  numbers  can  be  entered  either  with  or  without  an  exponent  being  specified.  Here  are 
some  examples  of  real  numbers:  “1234.012”,  “-0.987895”,  “.1239876”,  “1.334455e+0r’.  Complex  num¬ 
bers  will  be  entered  as  two  real  numbers  on  the  same  line,  separated  by  a  space;  with  the  real  part  entered 
first. 


When  the  processor  is  ready  for  another  command  it  will  respond  with  a  prompt.  The  prompt  will  be 
“SAR>”.  If  an  illegal  command  is  entered  the  processor  will  respond  with  an  error  message,  preceding  the 
prompt.  All  error  messages  will  start  with  a  “?”  as  the  first  character  on  the  fine. 


17 


TABLE  7 


Control  and  Diagnostic  Interface  Commands 


Command 

Number  of 
data  lines 

Type 

Function 

Reboot 

— 

— 

Reboot  the  processor 

Restart 

— 

— 

Restart  the  processor 

Init 

2 

Integer 

Load  various  control  registers 

Run 

— 

— 

Form  images  on  a  continuous  basis 

Stop 

— 

— 

Stop  execution  and  \wait  for  command 

Status 

— 

— 

Dump  system  status  message 

Step 

— 

— 

Process  one  image  frame  and  stop 

StepN 

1 

Integer 

Process  N  image  frames  and  stop 

Debug 

— 

— 

Enter  debugger 

Xdebug 

Exit  debugger 

Loadref 

31,744 

Complex 

Load  reference  kernels 

Loadequal 

8,192 

Complex 

Load  Equalization  weights 

Loadiqeven 

48 

Real 

Load  l/Q  filter  weights  for  even  sequence 

Loadiqodd 

48 

Real 

Load  l/Q  filter  weights  for  odd  sequence 

Loadrcs 

2048 

Real 

Load  RCS  weights 

Dumpinit 

2 

Integer 

Dump  parameters  input  by  Init  command 

Dumpref 

31,744 

Complex 

Dump  reference  kernels 

Dumpequal 

8,096 

Complex 

Dump  Equalization  weights 

Dumpiqeven 

48 

Real 

Dump  l/Q  filter  weights  for  even  sequence 

Dumpiqodd 

48 

Real 

Dump  l/Q  filter  weights  for  odd  sequence 

Dumprcs 

2048 

Real 

Dump  RCS  weights 

Selftest 

— 

— 

Run  Self  test  once 

SelftestN 

1 

Integer 

Run  multiple  passes  of  selftest 

kinkiest 

“ — 

— 

Run  test  of  fiber  interface  once,  with  no 
external  fiber  loopback  cable  in  place 

LinktestN 

1 

Integer 

Run  multiple  passes  “linktesf 

Linklestf 

- — 

— 

Run  tester  of  fiber  interface  once,  using  a 
loopback  cable 

LinktestfN 

1 

Integer 

Run  multiple  passes  of  fiber  interface  test 

During  acceptance  testing,  it  is  likely  that  the  S  AR  processor  will  be  controlled  using  the  same  work¬ 
station  that  controls  the  data  source  and  siiik.  Here  is  a  representative  sequence  of  events  for  testing  the  S  AR 
processor: 
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1 .  The  workstation  issues  the  “reboot”  command.  This  initializes  the  processor. 

2.  The  workstation  issues  a  “stop”  command.  As  discussed  in  Section  2.2.2.1,  the  “reboot”  com¬ 
mand  puts  the  processor  in  a  mode  where  it  is  ready  to  accept  data.  One  reason  for  issuing  a 
“stop”  command  is  so  that  a  “run”  command  can  be  given  later.  The  prompt  back  from  this  later 
“run”  command  will  indicate  that  the  SAR  processor  is  ready  to  accept  data. 

3.  The  workstation  issues  the  “Init”  command. 

4.  The  workstation  issues  the  commands  “loadref’,  “loadequal”,  “loadiqeven”,  “loadiqodd”, 
“loadrcs”.  This  loads  the  required  constants  into  the  processor.  This  step  involves  the  transfer  of 
on  the  order  of  a  million  characters.  At  9.6  Kbaud  this  is  likely  to  take  approximately  17  minutes 
or  around  4  minutes  at  38.4  Kbaud — ^assuming  that  the  workstation  and  processor  are  able  to 
exchange  data  at  full  speed. 

5.  When  it  is  necessary  to  check  the  setup  data  to  the  SAR  processor,  the  workstation  issues  dump 
commands  to  read  the  data  back. 

6.  The  workstation  issues  a  “run”  command.  The  SAR  processor  indicates  that  it  is  ready  for  data 
by  giving  the  specified  prompt. 

7.  The  workstation  starts  the  data  sink.  This  is  the  interface  and  disk  subsystem  used  to  store  data 
from  the  SAR  processor. 

8.  The  workstation  starts  the  data  source.  This  is  the  interface  and  disk  subsystem  used  to  send  data 
to  the  SAR  processor. 

9.  The  data  source  stops  after  the  test  data  has  been  sent  to  the  processor. 

10.  The  workstation  issues  a  stop  command  to  the  processor.  The  processor  indicates  it  is  finished 
processing  data  by  giving  a  prompt  to  this  command.  It  is  not  necessary  for  the  stop  command  to 
verify  all  data  are  processed — i.e.  it  would  be  acceptable  to  leave  the  processing  of  the  last  few 
frames  incomplete  if  it  reduces  the  complexity  of  the  processor.  There  will  be  a  few  frames  of 
source  data  whose  images  will  not  be  checked  during  acceptance  testing. 

11.  Once  the  workstation  receives  a  prompt  from  the  stop  command,  it  shuts  down  the  data  sink. 

12.  The  worksttion  compares  processor  image  data  from  the  data  sink  with  reference  image  4ata 
Only  the  first  N  frames  of  data  will  be  compared,  where  N  is  no  more  than  three  frames  less  than 
the  number  of  frames  sent  by  the  source. 

2.2.2.1  Reboot.  This  command  is  intended  to  be  the  same  as  a  power  up  initialization.  The  proces¬ 
sor  should  do  the  following: 

1 .  Run  the  self  test  diagnostics — this  is  the  same  as  the  command  “selftest”. 

2.  Hush  all  buffers. 

3.  Initialize  the  setup  constants  (items  initialized  by  the  “init”,  “loadref’,  “loadequal”,  “load¬ 
iqeven”,  “loadiqodd”,  “loadrcs”)  to  reasonable  values.  These  initial  values  may  be  “hardwired” 
into  the  program  so  that  the  processor  may  generate  images  without  setup  constants  being 
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loaded  from  an  external  device.  The  resulting  images  may  have  poorer  quality  than  they  would  if 
a  set  of  setup  constants  were  loaded,  via  the  control  interface,  that  correspond  to  the  specific  data 
set  being  processed.  Alternatively,  the  setup  constants  could  be  loaded  from  a  non-volatile  mem¬ 
ory.  The  constants  would  be  loaded  into  non-volatile  memory  by  a  command  which  copies  the 
current  setup  constants  into  memory. 

4.  Start  accepting  input  data  if  there  is  any — ^this  is  the  same  as  a  “mn”  command. 

The  SAR  processor  must  be  able  to  “come-up”  (execute  a  reboot  command)  while  data  is  streaming 
into  its  input  port.  The  processor  may  ignore  this  data  until  it  is  up  and  ready  to  go.  The  processor  will  in¬ 
dicate  “ready”  by  giving  a  prompt  on  the  control  interface.  If  data  is  already  streaming  into  it  at  this  time, 
the  processor  will  pick  up  at  the  start  of  the  next  PRI.  Note  that  if  data  is  streaming  into  the  processor  while 
it  is  coming-up,  it  will  not  be  well  defined  as  to  where  in  the  stream  of  incoming  data  the  processing  will 
start.  In  a  carefully  controlled  test,  it  is  expected  that  the  input  data  stream  will  not  be  started  until  the  pro¬ 
cessor  has  given  a  prompt  indicating  that  it  is  ready. 

2.2.2.2  Restart,  This  conunand  is  the  same  as  the  “reboot”  command  except  that  the  setup  con¬ 
stants  will  be  left  alone  and  the  selftest  will  not  be  run. 

2.2.2.3  Init.  Inputs  the  following  two  words  of  setup  information,  in  the  order  given  below: 

1 .  An  integer  between  0  and  15  which  determines  which  polarizations  are  processed.  For  the  pur¬ 
pose  of  controlling  polarizations  this  integer  should  be  thought  of  as  4  binary  bits  (although  it  is 
input  as  a  decimal  integer).  Each  bit  enables  the  processing  of  a  polarization  as  follows:  W,  VH, 
HV  and  HH  respectively  where  the  MSB  enables  the  processing  of  VY  and  the  LSB  enables  the 
processing  of  HH.  For  example  the  number  5  would  enable  the  processing  of  VH  and  HH. 

2.  The  number  of  taps  in  the  FIR  filter  used  to  convert  input  video  to  baseband  I/Q.  This  will  be  an 
integer  between  8  and  48. 

If  no  “Init”  command  is  given  the  default  shall  be:  (1)  to  process  only  the  HH  polarization,  corre¬ 
sponding  to  a  value  of  1  for  the  first  word;  (2)  an  FIR  filter  length  of  8. 

2.2.2.4  Run.  This  command  enables  the  processing  of  data.  If  a  data  stream  is  already  coming  in, 
the  SAR  processor  will  start  processing  it  with  the  start  of  the  next  PRI — defined  by  the  next  Barker  se¬ 
quence  associated  with  data  for  the  HH  polarization.  If  there  is  no  data  stream  coming  in  the  processor  will 
start  processing  whenever  a  data  stream  starts  coming  in  (once  the  processor  is  ready).  The  processor  indi¬ 
cates  that  it  is  ready  to  process  any  incoming  data  by  giving  a  prompt  in  response  to  this  command.  If  sub¬ 
sequent  run  commands  are  given,  when  the  processor  is  already  enabled  for  processing,  the  processor  will 
respond  with  a  prompt,  leaving  processing  enabled. 

2.2.2.5  Stop.  This  command  disables  processing.  If  it  is  given  while  data  is  coming  in,  processing 
will  continue  until  the  end  of  the  current  frame.  It  is  OK  if  this  is  the  next  frame  instead  of  the  current  one. 

2.2.2.6  Status.  In  response  to  the  status  command  the  processor  will  respond  with  status  informa¬ 
tion.  The  format  of  this  information  will  be  left  up  to  the  Developers — each  Developers  may  implement  the 
status  checks  and  messages  differently.  The  status  information  will  not  exceed  20  lines  of  80  characters 
each.  At  a  minimum  the  status  information  shall  include  the  following: 
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1 .  Which  polarizations  are  being  processed. 

2.  How  many  taps  are  being  used  in  the  video  to  baseband  FIR  filter. 

3.  Whether  the  processor  is  enabled  for  processing. 

4.  How  many  frames  have  been  processed  since  the  last  run  command. 

Step.  Run  for  a  single  fftune  and  then  stop. 

2.2.2.8  StepN.  This  command  takes  an  integer  between  1  and  32767  as  the  value  of  N.  It  runs  for 
the  number  of  frames  specified  by  N. 

2.2.2.9  Debug.  This  command  will  cause  control  of  the  RS-232  line  to  be  transferred  to  a  debug¬ 
ger.  It  is  left  to  the  discretion  of  the  Developers  as  to  the  commands  for  the  debugger.  It  is  expected  that  the 
capability  will  exist  for  examining  and  writing  to  memory  locations  within  the  SAR  processor.  When  the 
debugger  is  entered,  a  message  should  be  output  on  the  RS-232  line  saying  that  the  debugger  is  being  en¬ 
tered  and  what  the  command  is  to  get  back  to  normal  command  mode,  where  commands  can  once  again  be 
given  to  the  signal  processor. 

2.2.2.10  Xdebug.  This  command  will  exit  the  debugger.  This  command  is  ignored  if  the  debugger 
is  not  currently  active. 

2.2.2.11  Loadref.  This  command  loads  the  reference  kernels.  The  reference  kernels  are  range-de¬ 
pendent  matched  filters  which  are  convolved  with  the  radar  pulse  returns  to  yield  the  desired  images.  The 
kernels  are  precomputed  for  a  given  range  swath  in  the  host  and  downloaded  to  the  SAR  image  processor 
prior  to  operation.  Detailed  descriptions  of  the  kernel  and  weighting  functions  are  included  in  Appendix  A 
and  [12]. 

The  31  kernels  are  loaded  in  sequence  from  near  range  (kemelO)  to  far  range  (kemel30),  where  each 
kernel  is  a  vector  of  complex  numbers.  The  elements  of  each  kernel  are  loaded  in  order  from  index  0  to  index 
1023  (see  Figure  4),  and  each  element  is  composed  of  a  real  component  followed  by  an  imaginary  compo¬ 
nent. 


2.2.2.12  Loadequal.  This  command  loads  the  equalization  weights.  Equalization  weights  change 
slowly  and  can  be  assumed  constant  over  a  data  collection  period.  Therefore  the  equalization  weights  are 
precomputed  and  downloaded  to  the  SAR  processor  prior  to  operation. 

Equalization  weights  for  the  HH,  HV,  VH,  and  W  are  loaded  in  order  where  the  weights  for  each 
polarization  are  an  array  of  complex  numbers.  The  elements  of  each  array  are  loaded  in  order  from  index  0 
to  index  2047,  where  the  indices  correspond  to  the  ordered  output  samples  of  the  I/Q  filters  (see  Section 
2.1.3).  Each  array  element  is  composed  of  a  real  component  followed  by  an  imaginary  component. 

2.2.2.13  Loadiq.  Loadiqeven  and  Loadiqodd  commands  load  the  I/Q  filter  weights.  These  weights 
are  precomputed  and  downloaded  prior  to  operation.  Presently,  8-tap  FIR  filters  are  used  but  FIR  filters  with 
as  many  as  48  taps  shall  be  accommodated.  The  number  of  real  weights  input  by  this  command  is  always 
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equal  to  48,  but  only  the  first  N  weights  are  used  where  N  is  the  number  of  taps  specified  by  the  last  “Init” 
command.  Hie  even  and  odd  filter  weights  are  loaded  in  order  from  index  0  to  index  47.  The  indices  of  the 
filter  weights  tsjne^ond  to  the  FIR  processing  described  in  Section  2.1.3. 

2.2.2.14  Loadrcs.  This  command  loads  the  RCS  weights.JWeighting  is  applied  to  compensate  the 
amplitude  variasions  caused  by  beam-shape  modulation  in  elevation  and  R^  losses.  These  weights  are  com¬ 
puted  in  the  host  and  downloaded  prior  to  operation.  The  real-valued  RCS  weights  are  loaded  in  order  from 
index  0  (i.e.,  hot  range)  to  index  2047  (i.e.,  far  range) 

2.2.2.15  Dump  Commands.  The  commands  “dumpinit”,  “dumpref’,  “dumpequal”, 
“dumpiqeven”,  “dumpiqodd”,  and  “dumprcs”  will  dump  the  parameters  specified  earlier  by  the  correspond¬ 
ing  initAoad  commands.  The  order  of  the  numbers  output  will  be  the  same  as  it  is  for  input. 

2.2.2.16  Selftest.  Run  one  pass  of  the  self  test  diagnostics.  This  is  intended  to  run  the  same  diag¬ 
nostics  that  are  mn  at  system  boot  time.  If  this  is  not  practical,  a  reasonable  set  of  diagnostics  will  be  run 
instead.  If  the  diagnostics  pass,  they  will  output  the  line  “Self  test  passed”.  If  there  are  any  errors,  an  appro¬ 
priate  error  message  will  be  given.  The  first  character  in  a  line  corresponding  to  an  error  message  will  be  a 


2.2.2.17  SelftestN.  Rxm  N  passes  of  the  self  test  diagnostics,  where  N  is  specified  as  an  input  pa¬ 
rameter.  N  is  aa  integer  between  1  and  32767. 

2.2.2.18  Linktest.  Run  one  pass  of  a  test  of  the  fiber-optic  interfaces.  This  test  assumes  that  the  fi¬ 
ber-optic  interface  is  looped  by  locally,  without  actually  going  through  a  fiber.  This  test  will  transmit  a  pat¬ 
tern  and  then  verify  that  it  is  received  on  the  HotRod  receiver.  The  pattem(s)  used  are  left  to  the  discretion 
of  the  Developers.  This  test  can  be  run  without  the  need  to  move  any  cables.  “Linktestf  ’  described  below 
will  require  the  disconnection  of  the  normal  fiber-optic  cables  and  a  connection  of  a  loopback  cable. 

2.2.2.19  LinktestN.  Run  N  passes  of  the  “linktest”,  where  N  is  specified  as  an  input  parameter.  N 
is  an  integer  between  1  and  32767. 

2.2.2.20  Linktestf.  Run  one  pass  of  a  test  of  the  fiber-optic  interfaces.  This  test  is  the  same  as  “link- 
test”,  described  above,  except  that  it  requires  a  fiber-optic  loopback  cable — a  cable  which  coimects  the  SAR 
processor’s  fiber-optic  transmitter  to  the  fiber-optic  receiver. 

2.2.2.21  LinktestfN.  Run  N  passes  of  “linktestf’,  where  N  is  specified  as  an  input  parameter.  N  is 
an  integer  between  1  and  32767. 

2.2.3  Power  Reset 

In  addition  to  the  software  reboot  conunand  implemented  through  the  control  and  diagnostic  inter¬ 
face,  a  hardware  reset  capability  shall  be  included.  Operation  of  the  hardware  reset  button  will  cause  the 
SAR  processor  to  execute  the  normal  power-on  start-up  sequence.  This  start-up  sequence  will  be  function¬ 
ally  the  same  as  the  software  reboot  command. 
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2.3  FORM  FACTOR  CONSTRAINTS 


2.3.1  Size 

The  maximum  allowable  dimensions  for  the  processor  are  10.5”  in  height,  20.5”  in  length,  and  17.5” 
in  width.  These  dimensions  encompass  the  chassis,  cooling  fans,  power  supply  and  cable  headers  and  are 
consistent  with  the  use  of  the  processor  on  board  a  small  unmanned  air  vehicle  (UAV)  such  as  the  Leading 
Systems  Amber  UAV  [12]. 

2.3.2  Occupancy  and  ScalabUity 

The  functional  requirements  included  in  this  statement  of  work  only  encompass  the  processing 
through  the  step  of  image  formation.  In  the  future,  additional  functionality  may  be  required,  such  as  auto¬ 
matic  target  recognition  and  image  compression.  The  processor  architecture  should  be  scalable  to  support 
at  least  twice  the  processing  and  twice  the  aggregate  communication  bandwidth  as  that  implemented  in  the 
initial  configuration. 

In  addition  to  expansion  space  for  twice  the  computational  throughput  and  communication  band¬ 
width,  space  must  be  available  in  the  processor  box  for  the  addition  of  a  4-slot  6U  VME  chassis.  The  pro¬ 
vision  for  a  VME  chassis,  or  availability  of  four  contiguous  slots  in  an  existing  internal  chassis,  is  to  enable 
the  use  of  conunercial  VME  boards  for  display  or  subsequent  processing  of  the  images. 

2.3.3  Weight 

The  weight  for  a  fully-loaded  chassis,  including  the  4  slot  VME  chassis,  shall  be  less  than  60  pounds. 

2.4  ENVIRONMENTAL 

Air  cooling  in  an  non-condensing  environment  is  assumed.  The  temperature  range  of  the  ambient  air  will 
be0®Cto40®C. 

Due  to  cost  considerations,  shock  and  vibration  testing  wUl  not  be  performed.  However,  the  processor 
should  be  designed  so  that  it  can  be  operated  on-board  the  ADTS  aircraft  in  a  user-supplied  shock-mounted 
tray.  Measured  vibration  and  estimated  crash  loads  for  shock-mounted  equipment  on  the  Gulfstream  aircraft 
are  given  in  Table  8. 

2.5  POWER  SUPPLY 

The  power  supply  will  operate  with  an  input  voltage  of  24  to  32  volts  DC.  The  average^  input  power 
shall  not  exceed  500  watts  in  the  baseline  system. 

2.  The  average  as  computed  over  any  .5  second  interval. 
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TABLE  8 


Vibration  and  Shock  Loads 


Parameter 

Value 

Flight  Load  -  Worst  Case 

Vertical 

8.8  G 

Longitudinal 

6.0  G 

Transversal 

2.0  G 

Random  Vibration 

0.8  G  RMS 

Crash  Safety 

15  G,  11  ms 

Provision  to  handle  a  fully  populated  chassis  should  be  made  with  the  input  power  not  to  exceed  750 
watts.  The  power  supply  need  not  be  sized  to  handle  the  fully  populated  chassis  (750  watts  input)  provided 
there  are  provisions  to  incrementally  add  modules  to  the  initial  supply.  The  power  supply  should  conform 

to  the  requirements  of  MIL-STD-704D  for  input  transients  and  MIL-STD-461C  for  conducted  and  radiated 
emission  susceptibihty. 

2.6  FAULT  DETECTION,  ISOLATION  AND  TESTING 

2.6.1  Fault  Coverage  and  Isolation 

The  fault  coverage  and  isolation  achievable  in  the  processor  design  will  be  influenced  by  the  level  of 
integration  of  the  COTS  hardware  employed.  For  example,  a  system  assembled  from  COTS  chips  typically 
affords  more  opportunities  for  introducing  built-in  test  capability  than  a  system  assembled  from  COTS 
board  products.  Given  the  limited  time  duration  and  cost  constraints  of  the  RASSP  Benchmarks,  only  lim¬ 
ited  levels  of  fault  coverage  and  isolation  that  will  be  achievable  through  available  COTS  hardware.  Nev¬ 
ertheless,  it  is  important  to  demonstrate  that  the  RASSP  design  methodology  addresses  reliability  issues. 
Therefore,  a  goal  of  90  percent  fault  coverage  is  established  for  the  processor.  As  discussed  in  Section  2.6.3, 
the  appropriate  degree  of  fault  isolation  is  dependent  on  the  maintenance  concept  chosen  and  on  the  cost  to 
repair  versus  replace  a  given  isolation  group.  The  goal  for  isolation  is  to  isolate  faults  to  a  level  at  which 
replacement  of  the  faulty  group  is  commensurate  in  cost  with  replacement. 

These  fault  coverage  and  isolation  goals  are  included  to  demonstrate  a  capability  to  deal  with  design 
for  test  and  built-in  test  in  the  RASSP  process.  The  goals  are  not  intended  to  become  the  major  cost  drivers 
of  the  design.  Each  developer  is  required  provide  this  information  as  part  of  BTD-1  [12].  The  fault  detection 
and  isolation  approach  shall  be  defined  prior  to  or  as  part  of  the  response  this  BTD. 
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2.6.2  Data  Stimulus 


In  addition  to  whatever  test  vectors  and  test  patterns  the  Developer  may  provide  in  connection  with 
the  requirements  of  Section  2.6.1,  the  Benchmarker  will  supply  a  stimulus  dataset  consisting  of  unprocessed 
ADTS  data,  along  with  a  set  of  reference  images  formed  from  the  data  using  the  algorithms  described  in 
Section  2.1.  This  data  will  be  provided  on  an  8mm  Exabyte  8200  or  Exabyte  8500  tape  cartridge  in  uncom¬ 
pressed  tar  format. 

2.6.3  Maintenance  and  Testability 

Testability  requirements  are  a  function  of  the  maintenance  concept  chosen  to  support  the  benchmark 
processor.  The  choice  of  maintenance  concepts  is  limited  for  a  COTS  implementation,  whereas  many  main¬ 
tenance  concepts  are  applicable  for  custom  implementations.  In  either  case,  the  maintenance  concept  chosen 
must  provide  adequate  support  for  the  processor.  The  maintenance  concept  and  corresponding  software  and 
hardware  must  be  suitable  for  a  military  UAV  application.  Diagnostics  must  be  run  and  errors  must  be  re¬ 
ported  via  the  control  and  diagnostic  interface. 

Testability  of  the  prototype  processor  is  limited,  in  part,  by  the  design  of  all  COTS  elements  as  well 
as  any  COTS  building  blocks  used  to  integrate  these  elements.  At  a  minimum,  comprehensive  built-in  di¬ 
agnostic  capabilities  (e.g.,  power-up  memory  tests)  provided  by  the  COTS  product  manufacturer  must  be 
fully  utilized  and  any  errors  must  be  reported  by  the  system  through  the  diagnostic  and  control  interface. 
Test  capabilities  built  into  the  COTS  elements  must  be  fully  accessible  from  the  control  and  diagnostic  in¬ 
terface.  If  COTS  elements  with  suitable  capabilities  are  not  available,  then  semi-custom  diagnostics  must 
be  provided  by  the  COTS  manufacturer  at  the  expense  of  the  Developer  (e.g.,  a  custom  PROM  in  the  case 
of  hardware  computer  boards),  and/or  the  Developer  must  provide  semi-custom  integration  elements  which 
provide  the  necessary  test  capabilities  (e.g.,  a  COTS  interface  board  with  custom  software).  At  a  minimum, 
fault  isolation  must  be  to  the  COTS  element  level,  and  preferably  beyond  if  such  fault  isolation  capability 
is  provided  by  the  manufacturer  of  the  COTS  element.  For  example,  if  COTS  boards  are  used  (or  simulated 
in  software)  then  fault  isolation  must  be  at  least  to  the  board  level,  and  may  be  to  the  chip  level  if  such  di¬ 
agnostic  capabilities  are  available  for  the  COTS  boards. 


Many  maintenance  concepts  are  applicable  for  any  custom  designed  processor  components.  Testabil¬ 
ity  requirements  are  chosen  to  be  commensurate  with  the  maintenance  concept.  An  applicable  mainte- 
nance/sparing  concept  which  minimizes  the  estimated  life  cycle  cost  may  be  chosen  by  the  developer. 
Parametric  life  cycle  cost  estimation  programs  ([9],  [10])  for  both  hardware  and  software  can  be  used  to 
guide  the  choice.  For  example,  the  PRICE  HL  program  estimates  life  cycle  costs  for  28  different  standard 
maintenance  concepts  (e.g.,  discard  line  replacement  unit  at  failure,  replace  module  at  organization  and 
scrap  bad  module,  replace  module  at  equipment  and  repair  module  at  contractor).  Any  of  the  maintenance 
concepts  suitable  for  a  military  UAV  are  acceptable. 

Each  developer  is  required  provide  maintenance  and  testing  information  as  part  of  BTD-1  [12].  This 
information  shall  be  defined  prior  to  or  as  part  of  the  response  this  BTD. 
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2.6.4  Acceptance  Testing 


Acceptance  testing  will  consist  of  demonstrating  reliable  operation  of  the  prototype  processor.  The 
data  will  be  supplied  to,  and  collected  from,  the  prototype  using  the  data  source/sink  hardware  and  software 
supplied  by  the  Benchmarker.  Successful  execution  of  all  of  the  control  and  diagnostic  modes  indicated  in 
Table  7  shall  be  demonstrated  as  part  of  the  acceptance  testing.  Acceptance  testing  will  include  demonstrat¬ 
ing  reliable  operation  at  the  temperature  extremes  given  in  Section  2.4,  and  the  power  supply  extremes  given 
in  Section  2.5. 

2.7  IMPLEMENTATION 

The  Developer  must  evaluate  the  cost  of  three  processor  implementation  options.  The  first  option  is 
to  provide  for  image  formation  from  any  three  of  the  four  input  polarizations.  This  option  is  consistent  with 
the  requirements  set  forth  in  BTD-1.  The  second  option  is  to  provide  for  image  formation  from  any  one  of 
the  four  input  polarizations.  The  third  option  is  to  implement  as  much  functionality  as  possible  with  a  total 
cost  constraint  of  $500K  or  less  for  the  Benchmark.  In  all  cases,  the  polarization  of  the  data  to  be  imaged 
must  be  selectable  from  among  the  four  polarizations  of  input  data,  the  designed  hardware  and  software 
must  be  fabricated  within  the  six-month  benchmark  cycle,  and  the  processor  should  meet  as  many  of  the 
criteria  in  Section  2.1  through  Section  2.6,  including  the  fault  coverage  and  isolation  goals  of  Section  2.6.1, 
as  possible. 

2.8  DOCUMENTATION 

2.8.1  Hardware 

A  complete  set  of  drawings  shall  be  provided  with  the  prototype  of  the  SAR  image  processor.  For 
parts  of  the  prototype  processors  that  are  COTS  (commercial  off  the  shelf),  some  of  these  requirements  may 
be  waived.  At  a  minimum,  the  drawings  must  include  both  simplified  and  detailed  block  diagrams.  Addi¬ 
tional  drawings  shall  include,  but  not  be  limited  to,  the  following: 

•  Individual  mechanical  drawings  of  chassis,  boards,  backplanes  and  connectors. 

•  Detailed  schematics  and/or  source  files  for  all  non-COTS  printed  circuit  boards,  MCMs, 
ASICS,  PALs,  FPGAs  and  PLDs. 

•  AH  source  files  and/or  schematics  for  any  programmable  devices  incorporated  in  the  sig¬ 
nal  processor,  including  PALs,  FPGAs,  and  complex  PLDs.  This  requirement  is  for  the 
lowest  level  description  that  was  used  in  the  course  of  designing  the  device. 

•  Parts  list  and  cost. 

•  Net  list  of  all  non-COTS  printed  circuit  boards. 

•  Full  Specifications  for  any  non-standard  or  proprietary  components. 

The  theory  of  operation  shall  be  documented  including. 
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•  Modes  of  operation  supported  and  the  protocols  for  the  test  and  diagnostic  defined  in 
Table  7. 

•  All  critical  timing  information. 

•  All  non-standard  interfaces. 

2.8.2  Software 

All  non-COTS  application  software  (i.e  software  developed  specifically  for  the  Benchmark  by  the 
Developer)  shall  be  provided  in  Ada.  Wherever  available,  COTS  application  source  code  shall  be  provided 
in  Ada.  Hard  copy  of  all  application  source  code  shall  also  be  provided.  The  intent  here  is  that  Ada  should 
be  used  except  where  significant  reductions  in  performance  or  increases  in  cost  would  result.  An  example 
would  be  the  case  where  an  Ada  development  environment  does  not  exist  for  the  target  processor. 

Software  documentation  shall  conform  to  best  coirnnercial  standards  and  practices. 

2.9  REPORTING 

Progress  reports  shall  be  provided  with  each  milestone  as  discussed  in  Section  5. 
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3.  DATA  SOURCE/SINK 


MIT  Lincoln  Laboratory,  at  the  direction  of  the  Government,  will  deliver  to  each  of  the  Developers  a 
data  source/sink  test  system  consisting  of  a  test  bench,  support  software,  input  stimulus,  output  data  com¬ 
parison  files,  and  a  User’s  manual.  This  system  shall  be  used  by  the  Developers  to  validate  the  operation  of 
their  SAR  processors  during  acceptance  testing. 

3.1  SYSTEM  DESCRIPTION 

This  section  describes  the  various  components  of  the  complete  test  system  to  be  used  by  the  Devel¬ 
opers.  The  layout  of  the  system  is  shown  in  Figure  6. 


Figure  6.  Basic  test  system  layout. 


3.1.1  System  Hardware 

The  delivered  hardware  will  consist  of  a  host  SPARC  processor.  Data  Fiber  Interface  (DFI)  board  and 
two  associated  RAID  sub-systems  for  providing  data  to  and  receiving  data  from  the  SAR  processor.  Con¬ 
nection  of  the  test  hardware  to  the  SAR  processor  will  occur  through  the  fiber-optic  interfaces  described  in 
Section  2.2.1.  The  configuration  of  the  data  source/sink  shown  in  Figure  6  includes  a  full  system  interface 
to  the  host  SPARC  (system  disk,  keyboard,  monitor,  tape  drive,  etc.)  which  will  allow  the  user  to  control  the 
operation  of  the  hardware  test  bench,  to  communicate  with  the  SAR  processor  through  the  control  and  di¬ 
agnostic  interface  outlined  in  Section  2.2.2,  and  to  implement  the  error  comparison  of  processed  output  im¬ 
ages  with  reference  images  provided  by  Lincoln  Laboratory.  That  is,  the  data  source/sink  control,  SAR 
diagnostic  conunands,  and  SAR  control  commands  are  integrated  on  the  data  source/sink  host  with  software 
supplied  by  Benchmarker.  Data  transfer  rates  for  the  data  source/sink  are  shown  in  Figure  7. 
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AVERAGE  DATA 
TRANSFER  RATES 


13.72  MB/s  @  MAX  PRF 
4.57  MB/S  @  MIN  PRF 


22.8  MB/s 
18.24  MB/S 


34.15  MB/S  @  MAX  PRF 
40.0  MB/s  @  SYSTEM  MAX 

27.32  MB/s  @  MAX  PRF 
32.0  MB/s  @  SYSTEM  MAX 


9.1  MB/s  @  MAX  PRF 
10.67  MB/S  @  SYSTEM  MAX 


Figure  7.  Data  tranter  rates  for  data  source/sinL 


3.1.2  Support  Software 

Lincoln  Laboratory  will  provide  a  graphical  user  interface  (GUI)  to  operate  both  the  hardware  test 
bench  and  to  communicate  with  the  SAR  processor  using  the  control  and  diagnostic  serial  port.  This  inter¬ 
face  will  already  be  installed  on  the  hardware  test  bench  and  will  provide  a  convenient  means  of  performing 
the  validation  of  operation  inside  its  SAR  processor.  This  software  will  implement  the  command  set  out¬ 
lined  in  Section  2.2.2  as  weU  as  provide  additional  functionality  and  ease  of  use.  In  addition,  Lincoln  Lab¬ 
oratory  will  also  deliver  a  set  of  primitives  for  extracting  key  information  from  the  data  source/sink  test 
bench  for  the  purposes  of  debugging  and  diagnostics. 
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3.2  SYSTEM  OPERATION 


The  following  section  gives  an  brief  overview  of  the  operations  of  test  system: 

3.2.1  Installation 

Following  the  system  layout  diagram  above,  installation  of  the  Lincoln  Laboratory  test  system  con¬ 
sists  solely  of  the  connection  from  the  data  source/sink  test  bench  to  the  SAR  processor  using  the  fiber-optic 
interfaces  and  the  connection  of  the  SPARC  processor  to  the  SAR  processor  through  the  RS-232  interface. 

3.2.2  Diagnostics 

After  installation,  the  GLU  can  be  used  to  perform  diagnostics  on  both  the  hardware  test  bench  and 
the  SAR  processor.  In  addition,  a  text  window  allows  the  Developer  to  input  commands  to  the  SAR  proces¬ 
sor  in  the  manner  described  in  Section  2,2.2.  Thus,  diagnostic  commands  created  by  the  Developer  for  its 
SAR  processor  which  are  outside  the  scope  of  those  defined  in  Section  2.2.2  can  easily  be  utilized  through 
the  provided  software.  Lincoln  Laboratory  will  also  provide  a  set  of  software  primitives  which  can  be  ac¬ 
cessed  in  the  same  fashion  as  any  Developer-defined  commands  and  which  can  be  used  to  obtain  informa¬ 
tion  inside  the  hardware  test  bench  in  a  more  rigorous  fashion.  This  will  help  aid  the  Developer  in  any  sort 
of  debugging  situation  as  well. 

3.2.3  Processing 

Using  the  graphical  interface,  the  Developer  can  download  all  of  the  necessary  input  files  (I/Q  coef¬ 
ficients,  reference  kernels,  etc.)  to  the  SAR  processor,  access  the  input  stimulus  file  and  move  it  into  the  DFI 
test  bench,  run  the  processor,  extract  the  processed  image  data  from  the  SAR  processor,  store  the  results  on 
the  workstation,  and  perform  an  error  comparison  with  a  reference  output  image  set  according  to  the  accu¬ 
racy  requirement  described  in  Section  2.1.1.  A  more  detailed  description  of  such  acceptance  testing  is  out¬ 
lined  in  Section  2.2.2. 


31 


4.  METRICS 


4.1  INTRODUCTION 

All  metrics  asscx:iated  with  Benchmark-2  are  described  in  this  section.  However,  not  every  metric 
identified  in  this  section  will  necessarily  be  used  in  the  Benchmark-2  Evaluation  Report.  Additional  metrics 
may  also  be  devised  as  Benchmark-2  progresses.  The  metrics  which  are  currently  believed  to  be  essential 
for  developing  a  comprehensive  evaluation  report  are  identified  in  Section  5  as  deliverables  which  the  De¬ 
veloper  must  collect  and  supply  to  the  Benchmarker  during  the  course  of  Benchmark-2  execution.  In  some 
cases,  only  estimates  of  the  required  metrics  or  parameters  will  be  available.  In  such  cases,  the  Developer 
wiU  supply  a  best  estimate  with  a  rationale  (basis)  for  the  estimate. 

Two  approaches  will  be  applied  to  evaluate  the  RASSP  process  and  products.  In  the  first  approach, 
commercially  available  parametric  cost  estimation  packages  will  be  utilized,  primarily  to  obtain  estimates 
of  cost  and  schedule  to  serve  as  the  current  practice  reference.  The  most  comprehensive  packages  are  the 
Parametric  Review  of  Information  for  Costing  and  Evaluation  (PRICE)  and  System  Evaluation  and  Estima¬ 
tion  of  Resources  (SEER).  These  packages  are  discussed  in  Section  4.2.  In  a  second  approach,  metrics  de¬ 
rived  from  basic  principles  will  be  collected  and  utilized  as  a  basis  for  evaluating  specific  areas  of  RASSP 
product  and  process  development.  Such  development  areas  include  productivity  measures  of  the  RASSP 
process  such  as  lines  of  code  per  day  produced,  ease  of  use  of  the  design  environment,  performance  and 
complexity  of  the  product,  quality  of  the  product,  cost  of  the  process  and  the  product.  The  metrics  formu¬ 
lated  for  these  and  other  areas  are  discussed  in  Section  4.3. 

As  the  RASSP  program  develops,  redundancies  between  the  metrics  derived  from  the  parametric  cost 
estimators  (Section  4.2)  and  the  process  and  product  metrics  (Section  4.3)  will  be  identified  and  eliminated. 
Metrics  that  do  not  correlate  with  the  observed  performance  of  the  RASSP  process  and  products  will  be 
modified  or  replaced.  In  this  way,  the  set  of  metrics  will  be  continually  refined  over  the  duration  of  the 
RASSP  program. 

Since  a  primary  goal  of  the  benchmark  activity  is  quantitative  measurement  of  RASSP  related  im¬ 
provements  to  design,  it  is  anticipated  that  the  collection  and  analysis  of  metrics  for  this  purpose  will  require 
a  non-trivial  effort  on  the  part  of  the  Developers  and  the  Benchmarker.  In  formulating  the  Benchmark  Exe¬ 
cution  Check  List,  the  Developer  should  indicate  the  estimated  cost  to  collect  the  metrics  identified  in  Sec¬ 
tion  5.2  according  to  the  breakdown  of  deliverables  provided  in  Table  28  through  Table  40. 

4.2  PARAMETRIC  COST  ESTIMATORS 

Progress  is  measured  in  terms  of  costs,  which  are  defined  in  the  general  sense  where  expense,  devel¬ 
opment  time,  and  manpower  requirements  are  considered  to  be  “costs.”  There  are  many  software  tools  for 
cost  tracking  and  estimation,  and  the  benchmark  evaluation  approach  involves  several  such  tools. 
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A  technique  called  “detailed  bottom-up  estimating”  [6]  is  used  for  cost  tracking  purposes.  This  meth¬ 
od  is  analogous  to  a  bill  of  materials  and  labor  required  to  produce  each  subassembly  in  a  system,  and  the 
cost  of  integrating  the  subassemblies.  Actual  costs  collected  from  the  vendors  are  entered  into  a  computer 
system  using  a  Microsoft  Excel  spreadsheet  program,  which  has  a  data  format  compatible  with  all  of  the 
parametric  cost  estimation  programs  discussed  later.  This  approach  allows  data  to  be  conveniently  entered, 
organized,  analyzed  and  updated.  Data  accumulated  from  the  various  Developers  and  their  subcontractors 
at  different  phases  of  the  benchmarks  are  archived  in  a  database  for  future  reference.  Effects  such  as  the 
normal  progress  of  technology  in  the  absence  of  RASSP  can  be  factored  out  of  the  database  at  a  later  time, 
if  desired.  The  cost  tracking  feature  of  the  Microsoft  Project  planning  program  is  used  in  conjunction  with 
the  database  to  determine  the  incremental  and  overall  rate  of  progress  in  all  areas  of  interest. 

In  a  cost  estimation  technique  known  as  “parametric  estimating,”  a  cost  estimating  relationship  (equa¬ 
tion,  table  or  graph)  is  used  to  predict  cost  as  a  function  of  design  size,  performance  variables,  applicable 
technology  and  other  parameters.  The  Air  Force  provides  a  free  program  called  REVIC  which  performs 
software  cost  estimates  based  on  the  Constmctive  Cost  Model  (COCOMO)  [7].  In  addition,  there  are  at  least 
18  commercial  companies  which  provide  parametric  cost  estimation  products  for  software  [8].  Two  product 
lines  (PRICE  from  Martin  Marietta  PRICE  Systems  and  SEER  from  Galorath  Associates  Inc.)  are  of  par¬ 
ticular  interest  as  they  also  provide  hardware  cost  estimation  capabilities.  These  programs  require  a  variety 
of  inputs  to  perform  their  cost  estimation  function.  The  inputs  to  these  various  cost  estimation  programs 
form  a  basic  set  of  metrics  which  can  be  used  to  track  the  progress  of  RASSP,  and  other  metrics  can  be  added 
as  necessary.  Note  that  actual  benchmark  measurements,  not  the  predictive  cost  estimates  produced  by  the 
programs,  will  ultimately  measure  the  progress.  The  cost  estimates  produced  by  the  programs  can,  however, 
be  used  to  compare  the  complexity  of  one  benchmark  task  relative  to  another  benchmark  task.  In  addition, 
the  cost  estimates  can  be  used  to  identify  areas  in  which  progress  is  being  made  (e.g.,  a  metisured  cost  which 
is  less  than  the  current  practice-based  predictive  cost  estimates  by  a  factor  of  4  indicates  potential  achieve¬ 
ment  of  a  RASSP  goal  in  a  particular  area). 

The  benchmarker  will  use  the  PRICE  and  SEER  families  of  parametric  cost  estimation  tools  to  pro¬ 
duce  current  practice  baselines.  While  the  Developers  are  not  required  to  use  these  tools  (they  may  use  in¬ 
ternal  tools  which  they  intend  to  sell  as  part  of  the  RASSP  design  environment,  or  simply  maintain  a  rapid 
detailed  bottom-up  estimating  approach),  they  are  required  to  submit  input  data  (metrics)  to  the  benchmark 
i-ftam  SO  that  all  applicable  PRICE  and  SEER  estimating  models  can  perform  accurate  parametric  cost  esti¬ 
mates.  The  data  must  be  provided  in  a  format  convenient  for  entry  into  the  estimating  models  running  on  an 
IBM  PC-compatible  computer. 

4.2.1  PRICE  S  Software 

The  PRICE  Software  Model  applies  parametric  modeling  methods  to  estimate  the  acquisition  cost, 
software  sizing  cost,  and  operating  and  support  costs  for  computer  software.  The  acquisition  cost  estimates 
the  software  development  acquisition  process  in  each  of  the  following  phases: 

1 .  System  concept 

2.  System  software  requirements 

3.  Software  requirements  analysis 
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4.  Preliminary  design 

5.  Detailed  design 

6.  Computer  software  configuration  item  (CSCI)  test 

7.  System  test 

8.  Operational  test  and  evaluation  (OTE) 

9.  System  integrate  and  test. 

The  software  sizing  cost  estimates  the  number  of  instructions  in  terms  of  source  lines  of  code  for  both 
commercial  and  military  applications.  The  operating  and  support  costs  estimate  the  life  cycle  costs  for  the 
maintenance  phase,  including  software  maintenance,  enhancement,  growth,  and  modification. 

4.2.1.1  Acquisition  Mode.  For  the  acquisition  mode,  cost  estimates  are  made  using  an  BBS  (Es¬ 
timating  Breakdown  Structure)  which  is  a  sideways  tree  structure  that  provides  a  graphical,  hierarchal  rep¬ 
resentation  of  the  system  to  be  estimated.  Associated  with  the  element  at  the  system  level  are  the  output, 
global  (includes  schedule  multipliers,  cost  element  multipliers,  sensitivity  step  variables,  person-hours  per 
month,  person-month  decimals),  financial  factors  (includes  element  labor  rates,  overhead,  cost  of  money 
rates,  overtime  percentage,  general  and  administrative  rates,  profit  percentage,  economic  base  year,  escala¬ 
tion  on/off),  escalation  (includes  inflation  rates  from  1946-2025),  and  deployment  data  types  which  allow 
for  further  customization  of  the  cost  estimate.  Each  subordinate  element  in  the  tree  has  an  associated  data 
type  of  one  of  eight  categories-Development  CSCI,  Purchased  CSCI,  Furnished  CSCI,  Calibration  CSCI, 
Development  CSC  (computer  software  component).  Purchased  CSC,  Furnished  CSC,  and  Language- 
which  each  has  its  own  specific  variable  inputs.  Some  of  these  inputs  appear  in  more  than  one  category. 

4.2. 1.1.1  Development  CSCI. 


PLTFM 

CPLXM 

INTEGI 

INTEGE 

UTIL 

SCON 

SDR 

SSR 


platform;  the  customer’s  requirements  stemming  from  the  planned  operat¬ 
ing  environment;  measures  acceptability  of  portability,  reliability,  strac- 
turing,  testing  and  documentation. 

management  complexity;  effect  of  complicating  factors  (e.g.  development 
on  a  multinational  level  or  at  more  than  one  location) 

internal  integration;  level  of  internal  integration  of  lower  level  work  pack¬ 
ages  of  the  CSCI. 

external  integration;  level  of  integrating  CSCIs  into  the  next  higher  level 
system. 

utilization;  the  fraction  of  available  hardware  cycle  time  or  total  memory 
capacity  used. 

the  date  the  system  concept  effort  starts 

the  date  the  system  design  review  is  complete  or, 

the  date  the  software  specification  review  is  complete. 
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SRR 

date  the  system  requirements  analysis  review  is  complete 

PDR 

date  the  preliminary  design  review  is  complete 

CDR 

date  the  critical  design  review  is  complete 

TRR 

date  the  test  readiness  review  is  complete 

FCA 

date  the  functional  configuration  audit  is  complete 

PCA 

date  the  physical  configuration  audit  is  complete 

FQR 

date  the  formal  qualification  review  is  complete 

OTE 

date  the  operational  test  and  evaluation  is  complete 

4.2.1. 1.2  Purchased  CSCl. 

LANG 

source  language;  source  language  of  purchase  s/w  equipment. 

SLOG 

source  lines  of  code;  total  number  of  SLOG  to  be  purchased 

FRAG 

fraction  of  non-executable  code;  fraction  of  SLOGs  describing  the  type 
declarations  and  data  statements. 

APPL 

application;  expression  of  the  application  mix  of  instructions— low  values 
correspond  to  math  and  string-  manipulation;  high  values  emphasize 
Real-lime  Gommand  and  Control  and  interactive  applications. 

INTEGE 

see  Section  4.2.1. 1.1 

PCOST 

cost  of  purchased  component;  cost  of  purchased  software 

UNITS 

cost  units;  provides  the  unit  of  measurement  (hours,  months,  currency)  for 
the  PCOST  input 

RATE 

cost  of  labor  for  the  development  of  the  purchased  s/w. 

RATE  TIME  UNIT 

time  per  hour  or  per  month  used  for  the  RATE  input. 

PLTFM 

see  Section  4.2. 1.1.1 

4.2.1. 1.3  Furnished  CSCL 

LANG 

see  Section  4.2. 1.1. 2 

SLOG 

see  Section  4.2.1. 1.2 

GOST 

the  cost  of  the  software  to  be  calibrated 

FRAG 

see  Section  4.2.1. 1.2 

APPL 

see  Section  4.2. 1.1.1 

INTEGE 

see  Section  4.2.1. 1.1 

PLTFM 

see  Section  4.2.1. 1.1 
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4.2.1. 1.4  Calibration  CSCl.  Runs  PRICE  backwards  using  performance  characteristic  of  recent  pre¬ 
vious  projects  to  calibrate  the  current  cost  estimation. 


PLTFM 

see  Section  4.2. 1.1.1 

CPLXM 

see  Section  4.2. 1.1.1 

INTEGI 

see  Section  4.2. 1.1.1 

um 

see  Section  4.2. 1.1.1 

COST 

see  Section  4.2. 1.1.1 

SDR  or  SSR 

see  Section  4.2. 1.1.1 

SCON 

see  Section  4.2. 1.1.1 

SRR 

see  Section  4.2.2. 1.1 

PDR 

see  Section  4.2.2. 1.1 

CDR 

see  Section  4.2.2. 1.1 

TRR 

see  Section  4.2.2. 1.1 

FCA 

see  Section  4.2.2. 1.1 

FQR 

see  Section  4.2.2. 1.1 

OTE 

see  Section  4.2.2. 1.1 

4.2 A.  1.5  Development  CSC. 

INTEGI 

see  Section  4.2. 1.1.1 

INTEGE 

see  Section  4.2. 1.1.1 

UTIL 

see  Section  4. 2. 1.1.1 

SSR 

see  Section  4.2. 1.1.1 

PDR 

see  Section  4.2.2. 1.1 

CDR 

see  Section  4.2.2. 1.1 

TRR 

see  Section  4.2.2. 1.1 

FCA 

see  Section  4. 2.2. 1.1 

4.2. 1.1.6  Purchased  CSC. 

LANG 

see  Section  4.2. 1.1. 2 

SLOC 

see  Section  4.2. 1.1. 2 

FRAC 

see  Section  4.2. 1.1. 2 

APPL 

see  Section  4.2. 1.1. 2 
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INTEGE 

see  Section  4.2. 1.1.1 

PCOST 

see  Section  4.2. 1.1. 2 

UNITS 

see  Section  4.2. 1.1. 2 

RATE 

see  Section  4.2. 1.1.2 

RATE  TIME  UNIT 

see  Section  4.2. 1 . 1 .2 

4,2. LI. 7  Furnished  CSC . 

LANG 

see  Section  4.2.1. 1.2 

SLOC 

see  Section  4.2. 1.1. 2 

FRAC 

see  Section  4.2. 1.1. 2 

APPL 

see  Section  4.2. 1.1. 2 

INTEGE 

see  Section  4.2.1. 1.1 

4.2.1. 1.8  Language. 

LANG 

see  Section  4.2. 1.1.2 

SLOC 

see  Section  4.2. 1.1.2 

FRAC 

see  Section  4.2. 1.1. 2 

CPLXl 

complexity  1;  a  quantitative  description  of  the  relative  effect  of  compli¬ 
cating  factors  such  as  product  familiarity,  personnel  skills,  software  tools, 
etc.  on  the  software  development  task. 

CPLX2 

hardware/software  interactions  complexity;  a  quantitative  description  of 
the  relative  effect  of  complicating  factors  such  as  new  hardware  develoj)- 
ment  and  hardware  developed  in  parallel  caused  by  hardware/software 
interactions. 

PROFAC 

productivity  factor;  an  empirically  derived  parameter  that  includes  items 
such  as  skill  level,  experience,  productivity,  and  efficiency. 

APPL 

see  Section  4.2. 1.1. 2 

NEWD 

new  design;  the  percentage  of  new  design  effort. 

NEWC 

new  code;  the  percentage  of  new  coding  effort. 

4.2.1^  Software  Sizing  Mode.  This  mode  estimates  the  number  of  instructions  in  SLOC  needed  for 

commercial  and  military  applications. 

4.2. 1.2.1  Commercial. 

INTEGRATION 

win  the  software  program  be  integrated  with  other  software  programs? 

DESIGN  REVIEW 

is  an  in-house  or  customer  design  review  required? 
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CODE  WALK-THROUGH 

TOP  DOWN  APPROACH 
MODULE  TESTING 
OUTP 

OUTS 

OUTD 

INPF 

OUTF 

SCRF 

COPT 

INPFV 

COMVA 

LANG 

TARSIZ 

SICAL 

REQG 

FBULK 


will  the  programmer  have  to  walk  through  the  program  with  peers  and 
offer  a  forum  for  its  discussion? 

will  the  top-down  approach  be  used? 

is  modular  testing  (build  a  little,  test  a  little)  required? 

output  pages;  the  number  of  unique  output  pages  directed  to  a  line  printer 
(one  output  page  equals  66  lines) 

output  screens;  the  unique  number  of  format  output  reports  or  data  format 
that  will  be  output  to  a  CRT  display  @  24  lines/screen. 

output  displays;  the  unique  number  of  format  graphic  outputs  that  will  be 
displayed  on  a  CRT  or  plotting  device. 

input  files;  a  quantitative  description  of  the  number  of  unique  input 
streams  to  the  software  package. 

output  files;  a  quantitative  description  of  the  number  of  unique  output 
streams  of  the  program 

scratch  files;  the  number  of  temporary  work  or  scratch  files  that  will  be 
used  internally  by  the  software  program  for  temporary  storage,  calcula¬ 
tions,  etc. 

control  options;  the  number  of  control  options  or  modes  of  operation  of 
the  software  program. 

input  variable/fields;  a  required  input  that  describes  to  the  model  the  num¬ 
ber  of  different  variable  fields. 

computed  or  created  variables;  describes  the  number  of  created 
tables/variables  used  by  the  software  program  for  various  calculations. 

language;  the  source  language  to  be  used  for  the  software  development 
effort. 

target  size;  the  number  of  SLOC  from  a  completed  software  program  for 
calibration  purposes. 

the  size  calibration  factor 

requirements  growth;  anticipated  growth  from  any  uncertainty  or  room 
for  revisions  in  the  original  system  requirements  stage. 

functional  bulkiness;  an  efficiency  rating  of  the  software  program  that 
takes  into  account  the  programmer’s  skill  and  the  effectiveness  of  avail¬ 
able  programming  tools  in  minimizing  the  amount  of  instructions  being 
written. 
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4.2. 1.2.2  Military. 


MILITARY/COMMERCIAL 

accounts  for  the  inherent  complexity  of  the  project  by  its  specification 
level  required  with  military  projects  generally  being  more  specific  and 
complex. 

INTEGRATION 

see  Section  4.2.1.2.1 

DESIGN  REVIEW 

see  Section  4.2. 1.2.1 

CODE  WALK-THROUGH 

see  Section  4.2. 1.2.1 

TOP  DOWN  APPROACH 

see  Section  4.2. 1.2.1 

MODULE  TESTING 

see  Section  4.2. 1.2.1 

OUTP 

see  Section  4.2. 1.2.1 

ALPD 

alphanumeric  displays;  a  quantitative  description  of  the  number  of  unique 
alphanumeric  display  formats-similar  to  OUTP. 

GRAFD 

graphics  displays;  the  unique  number  of  operator  graphic  display  formats 
for  rasters  or  other  types  of  graphic  displays,  X-Y  plotting  boards,  and 
other  real  time  command  and  control  devices  that  employ  designs  using 
pixels,  aspect  ratios,  etc. 

INPST 

input  streams;  software  digital  data  signals  received  by  a  CSCI  or  CSC 
that  contains  unique  address  data  that  instructs  the  receiving  module  con¬ 
cerning  the  use  of  the  message  data  contained  on  the  stream. 

OUTST 

output  streams;  software  digital  data  signals  generated  by  a  CSCI,  CSC, 
or  other  piece  of  operating  hardware  such  as  servo  mechanisms,  printers, 
etc. 

CSTATE 

control  states;  major  decision  points  in  a  software  program  that  branch 
into  two  or  more  optional  program  routines. 

INPMF 

input  message  field;  the  portion  of  an  INPST  or  OUTST  that  contains  the 
intelligence  being  transmitted  in  the  form  of  messages. 

INPDK 

operator  actions;  any  operator  activity  that  results  in  a  digital  signal  being 
sent  to  a  CSCI. 

INPAN 

input  analogs;  signals  which  are  converted  into  digital  signals  prior  to 
transmittal  to  the  CSCI. 

COMTA 

computer  or  created  tables;  the  number  of  data  elements  (digital  words  or 
acronyms)  that  are  accumulated  in  tables  (either  in  matrix  form  or  in 
active  storage.) 

FBULK 

see  Section  4.2. 1.2.1 

REQG 

see  Section  4.2. 1.2.1 

SICAL 

see  Section  4.2. 1.2.1 
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TARSIZ 

LANG 


see  Section  4.2. 1.2.1 
see  Section  4.2. 1.2.1 


4.2.1.3  Life  Cycle  (Operating  and  support)  Mode.  This  mode  estimates  software  maintenance,  en¬ 
hancement,  growth,  and  modification  costs. 


PLTFM 

UTIL 

SSR 

SCHFAC 

DEVCST 

DEVU 

RATE  TIME  UNIT 
RATE 


see  Section  4.2.1. 1.1 
see  Section  4.2. 1.1.1 
see  Section  4.2. 1.1.1 


schedule  fraction;  the  amount  of  software  development  schedule  accelera¬ 
tion  or  stretch  out. 

development  cost;  the  total  software  development  cost 

development  units;  the  units  (Hours,  Months,  Currency)  entered  for  the 
DEVCST  input. 

see  Section  4.2. 1 . 1 .2 

see  Section  4.2. 1 . 1 .2 


4.2.2  PRICE-M  Micro  Circuits  and  Electronic  Assemblies 

PRICE-M  consists  of  three  modes:  microcircuit,  module,  and  database.  The  micro  circuit  mode  em¬ 
ulates  the  procedures  and  processes  involved  in  the  design  and  fabrication  of  microcircuits.  The  module 
mode  represents  a  computerized  modeling  technique  designed  to  produce  cost  and  schedule  estimates  as¬ 
sociated  with  the  design  and  production  of  modules,  boards,  or  hybrids.  The  database  mode  allows  the  user 
to  place  frequently  used  components  into  files  which  are  then  specified  as  extra  input  files  in  the  module 
mode.  Indices  are  derived  from  the  calibration  process  based  on  cost  history.  An  (*)  indicates  optional  data. 

4.2.2.1  Module  Mode  Inputs. 

4.2.2. 1.1  General  A. 


QTY 

PROTOS 

LENGTH,  WIDTH 

LAYERS 

PLTFM 

NAME 


quantity  of  production  modules 
quantity  of  prototypes 
length  and  width  of  module  in  inches 
number  of  discrete  layers 

platform  (commercial  low,  commercial  high,  military  fixed,  military 
mobile  or  high  fixed  or  commercial  aircraft,  military  aircraft,  or  manned 
space) 

name  of  module 
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4.2.2.1.2  General  B. 


MBINDX 

manufacturing  index  based  on  cost  history 

BTYPE 

bard  type  (material  and  use  —  e.g,,  standard,  RF,  microwave,  or  power) 

BSIDE 

board  sides  (component  layers,  not  related  to  LAYERS  above) 

*BCOST 

board  cost 

*PTYPE 

package  type  (material  and  use,  as  BTYPE) 

*PPINS 

number  of  connections 

*PCOST 

package  cost 

*ATCOST 

assembly  and  test  cost 

4.2.2.1.3  PRICE-H  Interface. 

QTYNHA 

number  of  modules  to  be  integrated  and  tested  into  the  next  higher  level 
of  integration 

INTEGE 

electronic  integration 

HSINT 

hardware/software  integration  (based  on  amount  of  modifications,  sim¬ 
plicity  of  interface,  and  importance  of  timing) 

WEIGHT 

weight  (pounds) 

VOLUME 

volume  (cubic  feet) 

BWT 

board  weight  (pounds) 

PWT 

package  weight  (pounds) 

4.2.2.1.4  Development. 

ECMPLX 

experience  and  qualifications  of  engineering  team  based  on  amount  of 
modification,  technology  level,  and  personnel  experience) 

NEWDES 

percent  new  design 

*DESRPT 

percent  repetition  in  design  effort 

4.2.2.1.5  Development  Schedule. 

DSTART 

design  start  date 

DFPRO 

date  of  completion  of  first  prototype 

DLPRO 

design  end  date  or  date  of  qualification  of  last  prototype 

DBINDX 

development  index  based  on  cost  history 
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4. 2. 2. 1.6  Production  Schedule. 


PSTART 

production  start  date 

PFAD 

date  of  completion  of  first  production  unit 

PEND 

production  end  date 

*MAUTO 

level  of  automation  of  assembly  and  testing  (based  on  automation  pro- 
cess-none,  semi,  or  full-  and  description  of  assembty,  such  as  robot 
assembly,  standard  assembly,  or  all  hand  insertion) 

MMAT 

level  of  experience  and  maturity  of  manufacturing  process  (based  on  new, 
similar,  or  same  process  and  description  of  difference  in  process) 

4.2,2. L7  Supplemental  Information. 

YRECON 

year  of  economics  (refers  to  cost  outputs) 

YRBASE 

base  year  of  economics  (refers  to  cost  inputs) 

*YRTECH 

year  of  technology 

AUCOST 

average  unit  cost 

ETCOST 

engineering  total  cost 

PRCOST 

prototype  cost 

4.2.2.  L8  Component  Data. 

CNUM 

number  of  components 

CNAME 

component  name 

CELM 

number  of  active  components 

CTYPE 

t3^e  of  component 

CPKG 

component  packaging 

CPINS 

number  of  connecting  pins  and/or  pads 

CWT 

component  weight 

CCOST 

component  cost 

A.211.2  Microcircuit  Mode  Inputs. 

4.2.2. 2.1  General. 

QTY 

production  quantity 

PROTOS 

prototype  quantity 

LENGTH,  WIDTH 

length  and  width  of  chip  (mils) 
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PINS 

number  of  pins 

GATES 

number  of  gates 

XSTRS 

number  of  transistors 

CNAME 

component  name 

4.2.2.22  Development. 

DPLTFM 

design  platform  (ground,  mobile,  airborne,  or  space) 

SPLTEM 

system  platform 

DINDEX 

development  index  (based  on  speed  in  MHz  and  design  technology) 

CMPLX 

engineering  complexity  (based  on  personnel  experience  and  scope  of 
design  effort) 

NEWCEL 

percentage  of  library  circuit  cells  or  macros  needed  to  be  designed 

DESRPT 

percentage  of  design  repetition 

CADFAC 

CAD  factor  (based  on  CAD  features) 

TERAT 

number  of  design/prototype/test  integrations 

4,2.2.23  Production  A. 

PROFAC 

production  factor 

MINDEX 

manufacturing  index 

PKGFAC 

packaging  factor 

SUBFAC 

substrate  factor 

LOTQTY 

total  lot  quantity 

WSIZE 

wafer  diameter  (mm) 

FSIZE 

feature  size  (microns) 

4.2,2.2A  Production  B. 

CPYLD 

circuit  probe  yield 

ASMYLD 

assembly  yield 

OVLYLD 

overall  yield 

MSKLVL 

mask  levels 

DEFDEN 

defect  density 

MAUTO 

manufacturing  automation 

MMAT 

manufacturing  maturity 
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42.2,2.5  Development  Schedule. 


DSTRT 

development  start  date 

PTSRT 

prototype  start  date 

FIEND 

prototype  end  date 

TSTEND 

prototype  test  end  date 

DEND 

development  end  date 

4.2.22.6  Production  Schedule. 

PSTRT 

production  start  date 

PPEND 

pre-production  end  date 

PEND 

production  end  date 

4. 2. 2.2. 7  Supplemental  Information. 

YRECON 

year  of  economics 

AUCOST 

average  unit  cost 

4.2,2.3 

Database  Mode  Inputs. 

PLTFM 

platform 

YRBASE 

base  year 

Component  data  (see  Section  4.2.2. 1.8). 

4.2.3 

PRICE  H  Hardware  Systems 

Cost  estimates  are  made  via  an  Estimating  Breakdown  Stracture  (EBS).  The  EBS  is  a  sideways  tree 
stmcture  which  provides  a  graphical  depiction  of  the  system  to  be  estimated.  Fourteen  items  called  elements 
can  be  selected  from  the  EBS  for  editing,  copying,  moving,  deleting  or  processing.  The  6  primary  hardware 
operation  elements  are:  system,  assembly,  electro/mechanical,  structural/mechanical,  modified  and  calibra¬ 
tion.  The  3  integrating  operation  elements  are:  design  integration,  hardware/software  integration  and  hard¬ 
ware  integration  &  test.  The  5  specialized  elements  are:  purchased,  given  cost,  furnished,  thm-put  and 
multiple  lot  production.  Four  different  types  of  data  or  operations  may  be  associated  with  each  element:  in¬ 
put,  output,  global  and  escalation.  Input  variables,  or  metrics,  may  have  a  different  definition  and  value  for 
each  element  of  the  EBS.  Input  variables  can  be  grouped  into  11  categories  as  follows,  but  there  is  consid¬ 
erable  overlap  and  interaction  between  the  categories. 
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4^.3.1  Project  Magnitude.  The  number  of  development  and/or  production  units.  Included  in  this 
category  is  the  wdght,  volume  and/or  the  electronic  weight  or  packaging  density  of  the  assembly. 


QTY 

PROTOS 

PROSUP 


WECF 

WSCF 


USEVOL 


number  of  production  units 
number  of  prototypes 
prototype  support 
total  weight 
sttucmre  weight 

weight  of  electronics  per  cubic  foot 
weight  of  structure  per  cubic  foot 
total  volume 

fraction  of  total  volume  used  by  electronics 


4.2.3J  Customer  Specification  and  Reliability  Requirements.  The  specification  level,  operat¬ 
ing  environment  and  reliability  requirements  associated  with  the  end  use  of  the  product. 


PLTFM 

MREL 

EREL 


platform  type  (e.g.  car  vs.  spacecraft) 

mechanical  reliability  (estimated  Mean  Time  Between  Failures) 
electronic  reliability 


4.2.3.3  Complexity  of  Design.  A  measure  of  the  effort’s  technology,  producibility  (material,  ma¬ 
chining  and  assembly  tolerance  difficulty,  etc.)  yield,  platform  and  all  labor  required  to  produce  the  strac- 
tural  and/or  electronic  part  of  the  assembly. 


jjYBRID  percentage  for  each  type  of  electronics  that  consist  of  hybrids 

percentage  for  each  type  of  electronics  that  consist  of  integrated  circuits 

percentage  for  each  type  of  electronics  that  consist  of  large  scale  ICs 
(100-lK  gates) 

YLSI  percentage  for  each  type  of  electronics  that  consist  of  very  large  scale  ICs 

(IK-IM  gates) 

MCONST  a  constant  used  to  describe  material  and  style 

MF.YP  raw  material  type  code 

MCPLXS  manufacturing  complexity  of  the  structure 

MCPLXS  is  a  function  of  precision  of  fabrication  (PRECI),  machinability  of  material  (MI),  difficulty 
of  assembly  (MATUR),  number  of  parts  (NP)  and  platform  (PLTFM).  Additional  input  parameters  (e.g., 
HOGOUT  if  more  than  10%  of  slug  weight  is  machined  away),  including  historical  data,  can  also  be  ap¬ 
plied. 


MCPLXE 


manufacturing  complexity  of  the  electronics 
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MCPLXE  is  a  fiinction  of  the  type  of  electronics  (analog,  digital,  display,  etc.),  electronic  componen¬ 
try  (discrete  devices,  ICs,  hybrids,  etc.),  specification  (testing  level  varies  with  platform)  and  various  adjust¬ 
ments  (component  quality,  density  and  a  calibration  factor  based  on  historical  data). 

Calibration  procedures  use  actual  cost  data  from  completed  projects  to  determine  historical  values  for 
MCPLSX  and  MCPLXE.  This  operation  is  referred  to  as  ECIRP,  which  is  PRICE  spelled  backwards.  Inputs 
to  the  ECIRP  include: 


AUCOST 

average  unit  cost 

PTCOST 

production  total  cost 

PRCOST 

prototype  cost  (total  manufacturing,  tooling  and  test  equipment  cost  of  the 
prototypes) 

DTCOST 

development  total  cost  (total  engineering  and  manufacturing  cost  of 
development  phase) 

A  value  for  the  prototype  multiplier  (PRMULT)  calibration  factor  is  obtained  during  the  calibration 
process. 

4.2.3.4 

uals  or  team,  as 
effort. 

Complexity  of  Engineering.  The  experience,  skill  and  know-how  of  the  assigned  individ- 
applicable  to  the  specified  task.  This  is  a  measure  of  the  complicating  factors  of  the  design 

ECMPLX 

engineering  complexity 

SE 

systems  engineering  factor  (a  function  of  engineering  complexity  and 
development  schedule,  this  factor  multiplies  the  total  drafting  and  design 
costs  to  obtain  the  SE  cost) 

4.2.3.5  New  Design  and/or  Design  Repeat.  How  much  new  work  is  required.  The  amount  of  de¬ 
sign  that  can  be  taken  from  existing  design  drawings  and  the  amount  of  structure  repetition. 

NEWST 

new  structure  (amount  of  new  structural  design  effort) 

DESRPS 

design  repeat  of  structure  (amount  of  structural  repetition  in  a  particular 
design) 

NEWEL 

new  electronics 

DESRPE 

design  repeat  of  electronics 

4.2.3.6 

the  normal  time 

Schedule  Impact.  The  relative  impact  of  known  and  unknown  scheduling  conditions  on 
required  to  complete  the  project. 

PSF 

prototype  schedule  factor 

DSTART 

development  start  date 
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DEND 

development  end  date 

DFPRO 

development  first  prototype  complete  date 

DLPRO 

development  last  prototype  or  completion  date 

PSTART 

production  start  date 

PFAD 

production  first  article  delivery  date 

PEND 

production  end  date 

TGALD 

time  calibration  multiplier  for  development  schedule 

TGALP 

time  calibration  multiplier  for  production  schedule 

NSHIFT 

number  of  work  shifts  in  production  phase 

NFAGS 

number  of  facilities  in  production  phase 

4.2.3.7  Technology  Growth.  The  technology  of  hardware  production  is  continually  changing.  On¬ 
going  innovations  lead  to  more  efficient  manufacturing  processes,  materials,  support  tools  and  management 
practices. 

YRTECH  year  of  technology 

ZTECH  technology  improvement  Z-curve  (allows  user  to  control  rate  of  technol¬ 

ogy  improvement) 

TECDEL  technology  delay  (allows  forward  or  backward  time  adjustment  to  tech¬ 

nology  improvement  curve) 


4.2.3.8  Hardware/Software  Integration.  When  hardware  relies  on  software  for  operation,  it  is 
necessary  to  integrate  the  software  with  the  hardware 


HSINT 

LANG 

SLOG 

FRAG 

APPL 

GPLXM 


hardware/software  integration  factor 

source  language  used  in  the  software  development  effort 

number  of  source  lines  of  code  excluding  comments 

fiaction  of  non-executable  code  (DATA  statements,  etc.) 

application  (ranges  from  simple  applications  to  complex  real-time  com¬ 
mand  and  control  applications) 

management  complexity  (e.g.  software  developed  at  more  than  one  loca¬ 
tion) 


4.2.3.9  System  Integration,  Many  large  hardware  developments  involve  the  merging  of  two  or 
more  related  hardware  products  into  a  single  unified  system.  The  individual  products  often  have  widely 
varying  characteristics,  and  they  may  even  be  developed  by  different  organizations  or  companies.  Resources 
and  time  are  required  to  accomplish  total  system  integration.  Gost  and  schedule  estimates  are  developed  for 
this  activity  by  examining  the  level  of  integration  required  for  each  individual  subsystem,  and  using  the  re¬ 
sults  to  determine  the  effort  required  to  bring  subsystems  together  into  a  total  unified  operation. 
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QTYNHA 

INTEGE 

DSTTEGS 

EPLANS 

SPLANS 


quantity  next  higher  assembly  (number  of  units  to  be  integrated  and  tested 
at  next  higher  assembly  level) 

electronic  integration  factor 

structural/mechanical  integration  factor 

electronic  plans  and  procedures  as  related  to  integration  effort 

structural  plans  and  procedures  as  related  to  integration  effort 


42.3.10  Specialized  Costs.  Inputs  for  the  5  specialized  elements  are  readily  obtainable  and  in  many 
cases  provided  as  part  of  the  design  effort.  Purchased  elements  use  actual  costs  (including  handling),  and 
estimates  for  given  cost  elements  (e.g.,  multi-chip  modules  and  custom  ICs)  are  available  from  PRICE  M 
when  actual  costs  are  not  available.  Costs  associated  with  furnished  elements,  thru-put  elements  (items  add¬ 
ed  to  the  total  system  cost  without  any  additional  markup)  and  multiple  lot  production  are  listed. 


COST 

recurring  cost  of  purchased  items 

COSTTYPE 

cost  type  (constant  vs.  “as  spent”  units) 

CDFRAC 

fraction  of  a  custom  design  cost  allocated  to  a  module  cost  for  a  given 
cost  element 

DDRCST 

development  drafting  cost  of  a  given  cost  element 

DDRAFT 

development  drafting  calibration  multiplier 

DDECST 

development  design  cost  of  a  given  cost  element 

DDSIGN 

development  design  calibration  multiplier 

DSYCST 

development  system  cost  of  a  given  cost  element 

DPJCST 

development  project  management  cost  of  a  given  cost  element 

DPROJ 

development  project  management  calibration  multiplier 

DDACST 

development  data  cost  for  a  given  cost  element 

DDATA 

development  data  calibration  multiplier 

DPRCST 

prototype  manufacturing  cost  of  a  given  cost  element 

DTTCST 

development  tooling  and  test  equipment  cost  for  a  given  cost  element 

DTLGTS 

development  toohng  and  test  equipment  cost  calibration  multiplier 

GDTLGT 

global  development  tooling  and  test  sets  calibration  multiplier  (used  when 
DTLGTS  is  zero) 

PDRCST 

production  drafting  cost  for  a  given  cost  element 

PDRAFT 

production  drafting  global  multiplier  (used  to  adjust  drafting  costs  with¬ 
out  affecting  other  costs) 
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PDECST 

PDSIGN 

PPJCST 

PPROJ 

PDACST 

PDATA 

PPRCST 

PTTCST 

PTLGTS 

GPTLGT 

DCOST 

PCOST 

TCOST 

PIF 

UNTIEC 

RATE 

RATOOL 

GAP 

GAPFAC 

LOTFAC 

OPC 


production  design  cost  of  a  given  cost  element 
production  design  calibration  multiplier 
production  project  management  cost  of  a  given  cost  element 
production  project  management  calibration  multiplier 
production  data  cost  for  a  given  cost  element 
production  data  calibration  multiplier 

production  “production”  (fabrication,  assembly  and  test)  of  a  given  cost 
element 

production  tooling  and  test  equipment  cost  for  a  given  cost  element 

production  tooling  and  test  equipment  cost  calibration  multiplier 

global  production  tooling  and  test  sets  calibration  multiplier  (used  when 
PTLGTS  is  zero) 

development  cost  of  a  thru-put  element 
production  cost  of  a  thru-put  element 
total  cost  of  a  thru-put  element 

PRICE  improvement  factor  (how  cost/quantity  impacts  production)  for 
multiple  lot  production 

unit  learning  curve  for  multiple  lot  production 

production  rate  in  units  per  month 

rate  tooling  for  high  production  rate  multiple  lots 

production  break  (months) 

gap  factor  to  adjust  for  loss  of  learning  between  interrapted  multiple  lots 
lot  factor  to  adjust  for  transitions  between  lots  in  multiple  lot  production 
only  piece  cost  (cost  of  producing  only  one  unit) 


4.2.3.11  Other  Costs.  Pertinent  escalation  rates  and  mark-ups  for  general  and  administrative  charg¬ 
es,  profit,  cost  of  money,  internal  research  and  development,  tooling  and  test  equipment  cost  and  cost  of  en¬ 
gineering  change  notices. 


PTLGTS 

ETLGl 

ETLG2 

STLGl 

STLG2 

YRBASE 


production  tooling  and  test  equipment 

electronic  tooling  and  test  equipment  multiplier  for  initial  setup 

electronic  tooling  and  test  equipment  multiplier  for  maintenance  costs 

stractural  tooling  and  test  equipment  multiplier  for  initial  semp 

stmctural  tooling  and  test  equipment  multiplier  for  maintenance  costs 

base  year  economics  (inflates  actual  costs  from  previous  projects  for 
present-day  use) 
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YRECON 

DLEVE 

DLEVS 

DMULT 

PMULT 

SYSTEM 

ECNE 

ECNS 

4.2.4 

MTBF 

TF 

TMO 

EE 

FN 

CEND 

CPE 

CUR 

CMR 

TRE 

P 

PP 

FNSP 

CPPE 

CFIM 


year  of  economics  (defines  economic  base  of  output  costs) 

design  integration  level  for  electronics  (in-house  effort  required  for  pur¬ 
chased  or  furnished  items) 

design  integration  level  for  stmcture  (in-house  effort  required  for  pur¬ 
chased  or  furnished  items) 

development  multiplier  (linear  multiplier  to  all  development  cost  outputs 
for  markups) 

production  multiplier  (linear  multiplier  to  all  production  cost  outputs  for 
markups) 

development  systems  cost  calibration  multiplier 

engineering  change  notices,  electronic  (linear  multiplier  represents  per¬ 
centage  of  electronic  drawing  package  that  will  change  during  produc¬ 
tion) 

engineering  change  notices,  structural  (linear  multiplier  represents  per¬ 
centage  of  structural  drawing  package  that  will  change  during  production) 

PRICE-HL  Life  Cycle  System/Assembly  Control 

mean  time  between  failures,  assuming  corrective,  not  preventative,  main¬ 
tenance. 

time  to  repair  LRU 

time  to  repair  module  at  organization 

equipment  per  equipment  location 

allowable  failure  number  of  LRUs 

cost  of  engineering  department 

cost  of  production  engineering 

contractor  unit  repair 

contractor  module  repair 

meantime  to  repair  on-equipment  failures 

number  of  module  types 

number  of  part  types 

fraction  of  non-standard  parts 

cost  of  a  piece-part  replaced  on  equipment 

cost  of  fault  isolate  to  module  test  equipment 
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CFEP 

cost  of  fault  isolate  to  part  test  equipment 

FTSQF 

foot  square  floor  area  for  LRU  test  equipment 

FTSQP 

foot  square  area  for  module  test  equipment 

TC 

time  to  perform  ceckout  of  LRU 

CCOU 

cost  of  checkout  of  LRU  support  equipment 

FTSQC 

foot  square  area  for  LRU  checkout  test  equipment 

DSTART 

development  start  date 

DEND 

development  end  date 

PSTART 

production  start  date 

PEND 

production  end  date 

CUP 

average  cost  of  a  LRU  in  production 

CMP 

average  cost  of  a  module  in  production 

CPP 

average  cost  of  a  part  in  production 

YRECON 

year  of  economics 

YAT 

yearly  attrition  factor 

4.2.5  SEER-SEM  Software  Estimation  Model 

The  SEER  Software  Estimation  Model  creates  cost,  schedule,  risk,  and  maintenance  estimations  for 
software  development.  In  SEER-SEM,  software  volume  is  the  primary  driver.  It  can  be  entered  as  functions, 
as  lines  of  code,  or  as  both. 

The  WBS  (Work  Breakdown  Structure)  divides  the  overall  project  into  computer  programs  or  Com¬ 
puter  Software  Configuration  Items  (CSCIs)— the  highest  unit  of  a  software  application—which  can  be  fur¬ 
ther  subdivided  into  Computer  Software  Components  (CSCs),  which  can  be  further  subdivided  into 
Computer  Software  Units  (CSUs).  SEER-SEM  provides  cost  estimates  for  each  of  the  following  project 
phases: 

1.  System  concept 

2.  System  requirements  design 

3.  Software  requirements  analysis 

4.  Preliminary  design 

5.  Detailed  design 

6.  Code  and  CSU  test 

7.  CSC  integrate  and  test 

8.  CSCI  test 
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9.  System  integrate  through  operational  test  and  evaluation 

10.  Maintenance  and  operation  support. 

These  phases  correspond  to  the  traditional  waterfall  model  of  development  which  may  not  apply  to 
the  RASSP  design  methodology,  but  is  appropriate  for  representing  current  practice. 

Built-in  knowledge  bases  are  chosen  as  a  function  of  four  characteristics-platform  (avionics,  busi¬ 
ness,  ground,  manned  space,  missile,  mobile,  ship,  unmanned  space),  application  (CAD,  command/control, 
data  base,  diagnostics,  flight,  message  switching,  MIS,  mission  planning,  MMI/graphics,  office  automation, 
OS/executive,  process  control,  radar,  report  generation,  simulation,  software  development  tools,  test,  train¬ 
ing,  utilities,  other),  development  method  (Ada  development,  Ada  development  with  incremental  methods, 
Ada  full  use,  prototype,  spiral,  traditional  incremental,  traditional  waterfall),  and  development  standard 
(commercial,  2167A,  2167,  21 67A  minimal  set,  2167Afull  set,  1703, 483-490, 1679  with  IV&V.) 

The  values  of  the  aforementioned  four  characteristics  define  a  specific  type  of  WBS  item  which 
SEER-SEM  uses  to  generate  the  most  likely  values  and  ranges  for  an  extensive  list  of  input  parameters. 
These  parameters  can  then  be  modified  by  the  user  to  further  customize  and  refine  the  model  of  the  overall 
project  environment.  The  parameters  are  divided  into  sixteen  categories: 

4,2.5.!  Effective  Size.  Includes  the  following  parameters: 

4.2.5. 1.1  New  Lines  of  Code. 

4.2.5. 1.2  Pre-Exists,  Not  Designed  for  Reuse. 

•  Pre-Existing  Lines  of  Code 

•  Lines  to  be  Deleted  in  Pre-Existing 

•  Lines  to  be  Changed  in  Pre-Existing 

•  Percent  to  be  Redesigned 

•  Percent  to  be  Reimplemented 

•  Percentage  to  be  Retested 

4.2.5. 1.3  Pre-Exists,  Designed  for  Reuse. 

•  Pre-Existing  Lines  of  Code 

•  Lines  to  be  Deleted  in  Pre-Existing 

•  Percentage  to  be  Redesigned 
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4.2J^ 

4,2.53 


4.2.5.4 


4.2.53 


Percentage  to  be  Reimplemented 
Percentage  to  be  Retested 

Complexity.  An  overall  rating  of  the  software’s  inherent  difficulty. 

Personnel  Capabilities  &  Experience.  Includes  the  following  parameters: 

analyst  capabilities 

analyst  application  experience 

programmer  capabilities 

programmer  language  experience 

development  system  experience 

target  system  experience 

practices  &  methods  experience 

Development  Support  Environment.  Includes: 

modem  development  practices  use 

automated  tools  use 

logon  through  hardcopy  mmaround  time 

terminal  response  time 

multiple  site  development 

resource  dedication 

resource  and  support  location 

host  development  system  volatility 

practices  and  methods  volatility 

Product  Development  Requirements.  Includes: 

requirements  volatility 

specification  level/reliability 

test  level  (verification/validation) 

quality  assurance  level 

rehost  from  development  to  target 
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4.2.5.6  Product  Reusability  Requirements.  Includes: 


•  reusability  level  required 

•  software  impacted  by  reuse 

4.2.5.7  Development  Environment  Complexity.  Includes: 

•  language  type  complexity 

•  host  development  system  complexity 

•  application  class  complexity 

•  practices  and  procedures  complexity. 

4.2.5.8  Target  Environment.  Includes: 

•  special  display  requirements 

•  memory  constraints 

•  time  constraints,  real  time  code 

•  target  system  complexity 

•  target  system  volatility 

•  security  requirements 

4.2.5.9  Schedule  (optional).  Includes  the  required  schedule  (in  calendar  months) 

4.2.5.10  Staffing  (optional).  Includes: 

•  maximum  stalling  rate  per  year 

•  maximum  total  staff  available 

•  maximum  effort  available  (in  man-months) 

4.2.5.11  Probability.  An  overall  probability  of  completion  for  the  software  job  under  estimation. 

4.2.5.12  Software  Requirements  Analysis.  Includes: 

•  requirements  complete  at  contract 

•  requirements  definition  formality 

•  requirements  effort  after  baseline 
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4:2.5.13 


4.2.5.14 


4.2.5.15 


4.2.5.16 


4.2.5.17 

sists  of: 


Software  to  Software  Integration.  Includes: 

CSCIs  concurrently  integrating 
integration  organizations  involved 
external  interfaces  among  CSCIs. 

Software  to  Hardware  Integration.  Includes: 
hardware  integration  level 
unique  hardware  interfaces. 

Software  Maintenance.  Includes: 
years  of  maintenance 
separate  sites 

maintenance  grovith  over  life 
personnel  differences 
development  environment  differences 
annual  change  rate 
maintain  total  system. 

Other  Add-ons.  Includes: 
external  QA  Costs 
program  office  costs 
rV&V  costs. 

Average  Personnel  Costs.  The  average  costs  per  labor-month  for  the  base  year  which  con- 


direct  software  management 
software  system  requirements  analysis 
software  requirements  analysis 
software  design 
software  programming 
software  quality  assurance 
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software  configuration  management 
software  data  preparation. 


4.2.6  SEER-SSM  Software  Sizing  Model 

The  SEER  software  sizing  model  estimates  the  expected  size  of  a  software  project  based  on  qualita¬ 
tive/relative  inputs  without  the  use  of  databases. 

As  in  SEER-SEM,  the  WBS  (Work  Breakdown  Structure)  partitions  the  overall  project  into  modules- 
-CSCIs  which  can  be  further  divided  into  CSCs  which  can  be  further  divided  into  CSUs- whose  operational 
and  functional  characteristics  are  defined.  SEER-SSM  customizes  the  requirements  for  user-provided  input 
after  the  partitioned  modules  to  the  model  have  been  designated. 

SEER-SSM  requires  project  information  (company/organization,  project  name,  file  name),  module 
data  (name  of  software  unit  and  at  least  two  reference  modules  of  known  size  with  their  size  expressed  as 
in  DSI,  DEMI,  or  function  point  count),  and  four  user-provided  input  data  sets  (DSXs)~pairwise  data, 
PERT  sizing  data,  sorting  data,  and  ranking  data— for  execution. 

4.2.6.1  Pairwise  Data.  SEER-SSM  provides  unique  random  pairings  of  all  modules  in  the  project 
and  requires  the  user  to  make  a  binary  decision  concerning  their  comparative  sizes. 

4.2.6.2  PERT  Sizing  Data.  SEER-SSM  requires  the  user  to  estimate: 

•  the  total  number  of  lines  of  code  providing  the  lowest  possible  size  for  each  module 

•  the  most  likely  size  for  each  module 

•  the  highest  possible  size  for  each  module 

4.2.6.3  Sorting  Data.  SEER-SSM  provides  a  number  of  size  intervals  and  the  user  is  to  determine 
in  which  interval  the  size  of  each  particular  module  falls. 

4.2.6.4  Ranking  Data.  SEER-SSM  provides  unique  ordered  pairings  (ordered  tentatively  after  the 
three  previous  steps)  of  modules  in  the  project  and  requires  the  user  to  make  a  binary  decision  concerning 
their  comparative  sizes. 

4.2.7  SEER-IC  Integrated  Circuit  Model 

SEER-IC  uses  a  Work  Breakdown  Structure  (WBS)  to  create  cost  estimates  for  integrated  circuits 
(chips),  multi-chip  modules  (MCMs)  and  chips  on  MCMs.  Built-in  and  customized  knowledge  bases  may 
be  used  to  provide  information  for  estimates.  Built-in  knowledge  bases  are  selected  as  a  function  of  project 
type  (MCM,  complex  gate  array,  custom  chip,  monolithic  microwave  integrated  circuit,  “none,”  semi-cus¬ 
tom  chip  or  simple  gate  array),  platform  standard  (industrial,  commercial,  military  airborne,  military 
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ground,  military  ground  mobile,  military  sea,  “none,”  manned  space  or  unmanned  space)  and  acquisition 
category  (buy  and  integrate,  customer  furnished  equipment,  make,  “none,”  or  subcontracted  item).  User  cre¬ 
ated  (class)  knowledge  bases  can  be  created  if  desired.  Adjustment  factors  can  be  applied  for  specification 
generation,  design,  prototype  hardware  and  average  unit  production  in  each  of  the  class,  platform  standard 
and  acquisition  category  knowledge  bases.  Such  adjustments  are  used  to  acconunodate  variations  due  to 
fees  or  discounts.  Once  the  applicable  knowledge  bases  have  been  invoked  and  adjustments  applied,  infor¬ 
mation  is  entered  to  perform  estimates.  Most  input  variables  have  an  optional  associated  range  such  as 
“least,  likely,  most,”  or  “low,  nominal,  high.”  Application  ranges  for  all  required  inputs  (except  production 
quantity)  are  loaded  by  the  knowledge  bases.  Users  narrow  the  input  ranges  when  actual  values  are  known. 
Inputs  required  to  perform  an  estimate  fall  into  10  categories  as  described  in  the  following. 

4.2.7.1  Product  Description.  Includes: 

•  Chip  area  (die  area  in  square  millimeters) 

•  MCM  substrate  area 

•  number  of  devices  on  MCM 

•  feature  size  (minimum  line  width  and  spacing  in  microns) 

•  transistors  per  chip 

•  gates  per  chip 

•  input/output  pins  per  chip  or  MCM  (including  power) 

•  process  type  (wafer  technology  or  material  used  such  as  CMOS  exotic  material,  GaAs, 
linear,  NMOS,  PMOS,  SOS  or  TIL) 

«  package  type  (DIP,  flatpack,  leadless  chip  carrier,  pin  grid  array  or  unpackaged  die) 

•  wafer  diameter  and  operating  frequency  (very  high  for  >5(X)  MHz,  high  for  200-5(X)  MHz, 
nominal  for  50-200  MHz,  low  for  15-50  MHz  and  very  low  for  <15  MHz). 

4.2.7.2  Mission  Description.  Includes: 

•  Chip  classification  (custom,  semi-custom,  complex  gate  array  or  simple  gate  array) 

•  operating  environment  (commercial,  military  or  space). 

4.2.7.3  Program  Description.  Includes: 

•  New  design  (specifies  percentage  of  design  which  is  new) 

•  iterations  (number  of  re-design  and  re-manufacture  cycles  to  be  done  on  prototype  units 
until  satisfactory  performance  is  obtained) 

•  certification  level  (very  high  for  class  S,  high  for  upscreened  class  B,  nominal  for  class  B, 
low  for  industrial  and  very  low  for  conoimercial  grade  devices). 
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42.7.4 


Development  Environment.  Includes: 


•  Developer  capability  and  experience  (very  high  for  an  experienced  team  in  the  90th  per¬ 
centile,  high  for  75th  percentile,  nominal  for  50th  percentile,  low  for  30th  percentile  and 
very  low  for  a  novice  team  in  the  5th  percentile) 

•  development  tools  and  practices  (very  high  for  an  organization  with  modem  development 
practices  and  tools  in  the  90th  percentile,  high  for  75th  percentile,  nominal  for  50th  per¬ 
centile,  low  for  30th  percentile  and  very  low  for  an  organization  in  the  5th  percentile  using 
only  stand-alone  tools  with  no  logic/timing/fault  simulation) 

•  requirements  volatility  (extra  high  for  frequent  moderate  and  major  changes,  very  high  for 
frequent  moderate  and  occasional  major  changes,  high  for  occasional  moderate  changes, 
nominal  for  occasional  minor  changes  and  low  for  essentially  no  requirements  changes). 

4.2.7.5  Production  Environment.  Includes: 

•  Production  experience  (very  high  for  a  near-perfect  90th  percentile  production  team,  high 
for  75th  percentile,  nominal  for  55th  percentile,  low  for  35th  percentile  and  very  low  for  a 
non-functional  team  in  the  5th  percentile) 

•  production  tools  and  practices  (very  high  for  a  fully  automated  large  scale  facility  less 
than  2  years  old,  high  for  a  fully  automated  large-to-medium  scale  facility,  nominal  for 
highly  automated  medium  scale  facility,  low  for  a  semi-manual  small  scale  facility  and 
very  low  for  a  prototyping  facility). 

4.2.7.6  Program  Schedule.  Includes: 

•  Start  date  for  development 

•  prototype  quantity 

•  start  date  for  production 

•  optional  specified  yield  (percentage  of  production  units  surviving  testing  operations). 

4.2.7.7  Production.  Includes: 

•  Prior  production  units  (number  of  units  previously  produced  that  should  be  credited  to  this 
program) 

•  total  production  quantity 
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•  percentage  of  item  purchased  (percentage  of  item  that  will  be  developed  elsewhere  and 
integrated  into  the  system  as  a  purchased  item  or  customer-fiimished  equipment) 

•  production  unit  purchase  cost  (thruput  of  costs  for  purchased  items  not  included  in  the 
WBS). 

4.2.7.8  Probability.  Includes  the  probability  that  the  estimate  will  not  exceed  actual  cost  (90% 
used  in  risk  analysis  for  worst-case  estimate,  80%  for  fixed  price  bids,  50%  for  nominal  and  20%  for  cost 
plus  development). 

402.7.9  Economic  Factors.  Includes; 

•  Development  fee  (percent  of  development  costs  to  be  added  to  the  estimate  to  account  for 
additional  fees) 

•  production  fee  (percent  of  production  costs  to  be  added  to  the  estimate  to  account  for  addi¬ 
tional  fees). 

4.2.7.10  Project  Parameters.  Includes: 

•  System  quantity  (the  number  of  systems  being  built) 

•  fiscal  year  start  month 

•  currency  exchange  rate 

•  base  year  (the  year  which  represents  the  base  of  the  constant-year  dollars) 

•  cost  escalation  factor  (inflation/deflation  factor  to  convert  base  year  dollars  to  then-year 
dollars) 

•  database  (e.g.,  the  seeric93  database  is  chosen  for  performing  estimates  with  1993  tech¬ 
nology) 

4.2.8  SEER-H  Hardware  Estimation  Model 

SEER-H  uses  a  Work  Breakdown  Structure  (WBS)  to  create  cost  estimates  for  hardware  elements. 
Built-in  and  customized  knowledge  bases  may  be  used  to  provide  information  for  estimates.  Built-in  knowl¬ 
edge  bases  are  selected  as  a  function  of  element  type  (mechanical  or  electronic),  application  (hydraulics, 
signal  processor,  communications,  etc.),  platform  (ground,  air,  space,  fixed  or  mobile,  manned  or  un¬ 
manned),  development  standard  (commercial,  military  specification),  and  acquisition  category  (buy  and  in¬ 
tegrate,  customer  furnished  equipment,  make,  subcontracted,  or  “none”).  User  created  knowledge  bases 
(class)  can  be  created  if  desired.  Adjustment  factors  can  be  applied  for  specific  generation,  design,  prototype 
hardware,  and  average  unit  production  in  each  of  the  class,  platform  standard,  and  acquisition  category 
knowledge  bases.  Such  adjustments  are  used  to  accommodate  variations  due  to  fees  or  discounts.  Once  the 
applicable  knowledge  bases  have  been  invoked  and  adjustments  applied,  information  is  entered  to  perform 
estimates.  Most  input  variables  have  an  optional  associated  range  such  as  “least,  likely,  most,”  or  “low,  nom¬ 
inal,  high.”  Inputs  required  to  perform  an  estimate  fall  into  11  categories  as  described  in  the  following. 
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4.2.8.1  Inputs  Unique  to  Electronic  WBS  Elements. 

4.2.8.1.1  Product  Description.  Includes: 

•  Total  number  of  printed  circuit  boards  (PCBs) 

•  Circuitry  composition  (analog,  digital,  hybrid,  optical) 

•  discrete  components  per  PCB 

•  integrated  circuits  per  PCB 

•  I/O  pins  per  PCB 

•  clock  speed 

•  packaging  density  (extra  high  for  all  MCMs,  very  high  for  many  MCMs,  high  for  some 
MCMs  but  mostly  individual  packaging,  and  nominal  for  no  MCMs) 

•  IC  technology  (very  high  for  ULSI,  high  for  SLSI,  nominal  for  VLSI,  low^  for  LSI,  very 
low  for  MSI,  and  very  low-  for  SSI). 

4.2.8.1.2  Mission  Description.  Includes: 

•  Operating  environment  (air,  ground,  sea,  and  space) 

•  electronics  classification  (comm,  comp,  C/D,  electromagnetic,  nav) 

•  electronics  fault  detection 

•  electronics  fault  isolation. 

4.2.8.1.3  Program  Description.  Includes: 

•  New  design  (percentage  of  design  that  is  new) 

•  design  replication  (percentage  of  design  that  is  not  unique) 

•  certification  level  (very  high  for  manned  space  product,  high  for  unmanned  space  product, 
nominal-i-  for  military  aircraft  product,  nominal  for  commercial  aircraft  product,  nominal- 
for  military  ground-mobile  or  sea  product,  low  for  military  ground  system,  and  very  low 
for  commercial  grade) 

•  hardware  integration  level  (very  high  for  3-4  levels  of  integration,  high  for  2-3  levels  of 
integration,  nominal  for  1-2  levels  of  integration,  low  for  1  level  of  integration,  and  very 
low  for  no  integration  requirements). 
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4.2.8.2  Inputs  Unique  to  Mechanical  WBS  Elements. 

4.2. 8.2.1  Product  Description.  Includes: 


•  Weight  (pounds  or  kilograms) 

•  volume  (cubic  feet  or  liters) 

•  material  composition  (percent  aluminum/malleable,  steel  alloy,  commercial  exotic,  other 
exotic,  composite,  polymer,  ceramic) 

•  complexity  of  form  (extra  high  for  highest  precision  level  for  assembly,  very  high  for  pre¬ 
cision  assembly,  high  for  assembly  but  no  internal  movements,  nominal  for  assembly  with 
multiple  fasteners  but  no  internal  movements,  low  for  simple  assembly  with  standard  fas¬ 
teners,  and  very  low  for  no  assembly) 

•  complexity  of  fit  (extra  high  for  tolerances  less  than  1.5  mils,  very  high  for  tolerances 
between  1.5  and  5  mils,  high  for  tolerances  between  5  and  10  mils,  nominal  for  tolerances 
between  10  and  20  mils,  low  for  tolerances  between  20  and  40  mils,  and  very  low  for  tol¬ 
erances  between  40  and  60  mils) 

•  constraction  process  (very  high  for  highly  labor  intensive  fabrication  and  assembly,  high 
for  moderately  labor  intensive  fabrication  and  assembly,  nominal  for  low  labor  intensive 
fabrication  and  assembly,  low  for  minimum  labor  intensity  operations  with  50%  robotic 
assembly,  and  very  low  for  single  operator,  100%  robotic  assembly). 

4. 2. 8.2. 2  Mission  Description.  Includes: 

•  Operating  environment 

•  hardware  classification  (stracture,  mechanical,  hydraulic/pneumatic) 

•  operating  service  life  (in  hours) 

•  internal  pressure  (in  psi  or  kN/m2,  8000  psi  is  very  high  and  700  psi  is  very  low). 

4.2.8.2.3  Program  Description.  Includes: 

•  New  design 

•  design  replication 

•  certification  level 

•  hardware  integration  level. 

4.2.8.3  Inputs  Common  to  Both  Eectronic  and  Mechanical  WBS  Eements. 
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4.2.8.3.1  Development  Environment.  Includes: 


•  Developer  capability  and  experience  (very  high  for  90th  percentile,  high  for  75th  percen¬ 
tile,  nominal  for  55th  percentile,  low  for  35th  percentile,  and  very  low  for  5th  percentile) 

•  development  tools  and  practices  (very  high  for  CAD/CAM,  high  for  automated  tools, 
nominal  for  use  of  but  no  experience  in  CAD  but  not  CAM,  low  for  experimental  use  with 
automated  tools,  and  very  low  for  no  use  of  automated  design  or  manufacturing) 

•  requirements  volatility  (very  high  for  frequent  moderate  and  major  changes,  high  for  fre¬ 
quent  moderate  and  occasional  major  changes,  high  for  occasional  moderate  changes,  low 
for  occasional  minor  changes,  and  low  for  essentially  no  changes  at  all). 

4.2.8.3.2  Production  Environment.  Includes: 

•  Production  experience  (very  high  for  90th  percentile,  high  for  75th  percentile,  nominal  for 
55th  percentile,  low  for  35th  percentile,  and  very  low  for  5th  percentile) 

•  production  tools  and  practices  (very  high  for  CAD/CAM,  high  for  automated  tools,  nomi¬ 
nal  for  use  of  but  no  experience  in  CAD  but  not  CAM,  low  for  experimental  use  with  auto¬ 
mated  tools,  and  very  low  for  no  use  of  automated  design  or  manufacturing). 

4.2.8.3.3  Program  Schedule.  Includes: 

•  Required  development  schedule 

•  development  start  date 

•  prototype  quantity 

•  production  start  date 

•  production  learning  curve  (Cumulative  Average,  Unit  Theory) 

•  prior  production  units 

•  production  quantity. 

4.2.8.3.4  Purchased  Items.  Includes: 

•  Percentage  of  item  purchased 

•  production  unit  purchase  cost 

•  unit  purchase  cost 

•  probability  (90%  usually  worst  case  estimate,  80%  fixed  price  bid,  50%  most  likely,  20% 
optimistic). 
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4.2.83.5  Economic  Factors.  Includes; 

•  Engineering  hourly  rate 

•  manufacturing  hourly  rate 

•  material  cost  per  PCB/pound. 

4.2.9  SEER-HLC  Hardware  Life  Cycle  Model 

4.2.9.1  Project  Level  Parameters.  Includes: 

•  Project  name 

•  Operations  &  Support  start  date 

•  O&S  duration 

•  inflation  rate 

•  fiscal  year  start  month 

•  cost  input  base  year 

•  organizational  alternate  repair  hourly  labor  rate 

•  intermediate  alternate  repair  hourly  labor  rate 

•  depot  alternate  repair  hourly  labor  rate. 

4.2.9.2  Site  Parameters.  Includes: 

•  Site  identifier 

•  maintenance  shifts/week 

•  system  quantity 

•  date  operations  begin 

•  date  operations  end. 

4.2.9.3  Common  Support  Equipment  Parameters.  Includes: 

•  Support  suite 

•  production  cost/suite 

•  date  available. 
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4.2.9.4  Prime  Mission  Equipment  Parameters.  Includes; 

•  WBS 

•  PME  equipment  name 

•  quantity  per  system 

•  shipping  weight 

•  operating  hours  per  month 

•  PME  operating  hours  to  maturity 

•  PME  replacement  cost 

•  spares  sufficiency  probability 

•  consumable  cost  per  repair 

•  annual  resource  cost 

•  PME  mature  mean  time  between  failure 

•  condemnation  rate 

•  retest  OK  rate. 

4.2.9.4.1  PME  Item  Organizational  Maintenance  Details.  Includes: 

•  Mean  time  to  repair  at  organizational  level 

•  in  place  repair  rate 

•  organizational  shared  support  equipment 

•  organizational  hourly  labor  rate 

•  organizational  peculiar  support  equipment  date  available 

®  organizational  PSE  unit  cost. 

4.2.9.4.2  PME  Item  Intermediate  Maintenance  Details.  Includes: 

•  Mean  time  to  repair  at  intermediate  level 

•  intermediate  timi  around  time 

•  intermediate  shared  support  equipment 
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•  intermediate  hourly  labor  rate 

•  intermediate  PSE  date  available 

•  intermediate  PSE  production  unit  cost 

•  Not  Repairable  This  Station  rate. 

4.2.9.4.2  PME  Item  Depot  Maintenance  Details.  Includes: 

•  Mean  time  to  repair  at  depot  level 

•  depot  turn  around  time 

•  depot  shared  support  equipment 

•  depot  hourly  labor  rate 

•  depot  PSE  date  available 

•  depot  PSE  production  unit  cost. 

4.3  PROCESS  AND  PRODUCT  METRICS 

The  metrics  identified  in  Section  4.2  are  extracted  from  commercially  available  packages  for  program 
management.  These  metrics  attempt  to  quantify  factors  that  effect  the  (generalized)  cost  of  a  project  such 
that  each  package  gives  a  comprehensive  picture  of  the  development  and  production  costs  of  a  project. 

The  metrics  in  Section  4.3  are  directed  toward  specific  issues  of  performance  of  both  the  RASSP  pro¬ 
cess  and  products,  and  complexity  of  the  products.  For  the  most  part,  metrics  for  the  complexity  of  the 
RASSP  process,  such  as  the  total  number  of  source  lines  of  code  in  the  RDE,  are  not  required.  The  com¬ 
plexity  of  the  RASSP  process  is  measured  indirectly  through  productivity  metrics,  cost  of  the  tools,  and  ease 
of  use. 

Section  4.3.1  is  concerned  with  a  evaluation  of  the  RASSP  process  as  it  is  applied  to  develop  a  prod¬ 
uct,  and  not  an  evaluation  of  the  end  product.  However,  process  performance  is  not  unrelated  to  the  products 
being  developed,  and  so  measures  of  product  complexity  and  performance  are  required  to  fully  comprehend 
the  process  performance.  Without  measures  of  product  complexity,  the  performance  of  the  RASSP  process 
for  different  products  or  benchmarks  cannot  be  compared.  Without  an  understanding  of  product  perfor¬ 
mance,  success  of  the  RASSP  process  cannot  be  quantified  or  compared  to  ciurent  practice.  Products  in¬ 
clude  not  only  the  final  hardware  and  software  constituting  the  embedded  signal  processor,  but  also  a  host 
of  intermediate  and  supporting  items  such  as  documentation,  simulation  models,  schedules,  and  life  cycle 
cost  estimates.  Comprehensive  and  detailed  metrics  cannot  be  collected  for  every  intermediate  RASSP 
product  on  every  benchmark. 

Some  of  the  metrics  are  subjective  in  nature,  while  others  are  specific.  The  more  subjective  metrics 
are  apt  to  be  found  in  all  phases  of  the  project,  while  specific  quantitative  metrics  are  usually  limited  in  their 
focus.  Metrics  are  intended  to  measure  the  performance  of  the  process  and  not  the  people,  although  the  ex- 
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pertise  of  the  people  will  influence  the  success  and  efficiency  of  the  process.  Metrics  are  not  intended  to  be 
used  to  analyze  the  performance  of  individuals  involved  in  the  benchmark  execution. 

A  principal  concern  of  BTD-2  is  the  accuracy  with  which  hardware  is  developed  from  virtual  proto¬ 
types.  The  VHDL  used  to  produce  prototype  hardware  for  Benchmark-2  will  be  examined  and  compared 
with  delivered  hardware  together  with  the  VHDL  produced  in  Benchmark- 1. 

As  a  result  of  experience  gained  from  Benchmark-1,  a  form  for  tracking  software  defects  and  lines  of 
code  through  all  development  phases  will  be  used  for  Benchmark-2  [14]. 

4.3.1  Des^  Process 

The  different  tools  and  procedures  that  are  used  in  all  segments  of  the  benchmark  execution  are  con¬ 
sidered  in  the  evaluation.  Metrics  must  be  collected  to  quantify  the  value  of  both  the  tools  and  the  underlying 
methodology.  Although  the  ultimate  measure  of  success  is  the  reduction  in  the  design  cycle  time,  analysis 
of  progress  during  the  RASSP  program  requires  an  understanding  of  which  steps  in  the  RASSP  process  con¬ 
sume  the  majority  of  the  time,  and  where  improvements  in  the  time  required  to  execute  the  process  are  oc¬ 
curring. 


4.3.1.1  Tool  Evaluation.  For  each  major  tool  used  during  execution  of  the  benchmark,  the  metrics 

indicated  in  Table  9  are  required.  The  time  spent  using  the  tool  can  be  expressed  as  a  relative  or  percent  time 


TABLE  9 

Tool  Evaluation  Metrics 


Measurement 

Description 

Time 

Time  usage  associated  with  each  too!  {TOOL_USAGE) 

Assessment 

Value  of  tool  to  the  process  (TOOL_VAHJE) 

Assessment 

Heterogeneous  platform  support  (TOOL_OPEN) 

Assessment 

Seamless  access  to  design  data  (TOOL_D ACCESS) 

Assessment 

Human  interface  (TOOL_GUl) 

Assessment 

Interoperability  (TOOL_INTFCE) 

Assessment 

Unified  project  data  management  (TOOL_PROJDAT) 

Assessment 

Consistent  process  management  (TOOL_PROJMGT) 

Assessment 

Comprehensive  library  management  (TOOL_LIBMGT) 
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for  the  overall  process  or  step  in  the  process.  The  assessments  in  Table  9  will  be  assigned,  by  the  Developer, 
a  quality  factor  of  from  zero  to  four,  with  zero  corresponding  to  the  poorest  assessment  and  four  the  best. 
The  value  of  the  tool  ranges  from  nonessential,  meaning  the  step  could  be  completed  via  a  variety  of  other 
tools  or  methods,  to  essential,  meaning  that  the  tool  is  critical  to  a  timely  execution  of  the  step. 

4.3.1.2  Complexity.  The  size  of  a  project  contributes  to  complexity  in  a  non-linear  manner.  Some¬ 
thing  that  can  be  visualized  by  a  single  individual  is  not  linearly  scalable  to  a  large  project  with  its  attendant 
interfaces.  Well-defined  interfaces  using  standard  protocols  or  previously  developed  interfaces  are  prefera¬ 
ble  to  custom  designs.  A  project  must  be  divided  into  subprojects  which  are  distinct  with  clean  interfaces. 
The  number  of  disciplines  involved  in  a  project  contributes  to  complexity.  A  project  in  which  the  systems 
engineer  can  reasonably  be  expected  to  be  trained  is  inherently  less  complex  than  another  in  which  that  per¬ 
son  must  rely  on  the  technical  and  managerial  advice  of  others.  Solutions  which  push  the  state  of  the  art  will 
contribute  to  complexity.  The  benefits  of  repeated  utilization  are  not  realized  for  the  first  implementation. 

Three  fundamental  elements  will  form  the  basis  of  the  complexity  measurements:  reuse,  interfaces, 
and  comprehension. 

4.3. 1.2.1  Reuse.  The  services  in  this  category  must  perform  as  advertised  and  as  might  be  expected 
by  a  reasonable  person.  Elements  in  the  reuse  library  which  do  not  perform  as  advertised  will  impact  the 
complexity  because  they  distort  the  planning  process  and  the  schedule.  A  trigonometric  function  in  a  com¬ 
puter  program  is  not  inherently  more  complex  than  a  multiply  instruction  because  it  is  part  of  the  library. 
The  maturity  of  the  reuse  library  and  the  experience  of  the  users  are  important. 

The  metrics  required  to  evaluate  reuse  relate  to  the  time  saved  through  use  of  this  technique.  This  re¬ 
quires  meaningful  estimates  of  the  time  that  would  have  been  spent  in  creating  an  original  design,  the  time 
spent  in  exploring  and  evaluating  the  elements  of  the  reuse  library,  the  time  spent  in  incorporating  elements 
of  the  reuse  library  into  the  applicable  design,  and  finally  the  time  spent  in  re-evaluating  the  decision  be¬ 
cause  the  description  of  the  reuse  elements  was  inadequate  or  faulty  (a  defect,  report  as  specified  in  Section 
4.3. 1.3).  By  using  elements  of  a  library,  fewer  defects  are  introduced  into  the  design  and  this  must  be  esti¬ 
mated  from  the  anticipated  defect  rate.  Because  these  quantities  are  sometimes  nebulous,  it  shall  also  be  re¬ 
quired  that  the  Developer  estimate  the  time  and  cost  saved  in  bringing  the  product  to  the  end  user 
(REUSE_ENT_T  and  REUSE_END_C).  In  the  case  of  software,  the  reuse  metric  shall  also  be  expressed 
as  a  percentage  of  the  executable  lines  of  code.  This,  however,  does  not  by  itself  measure  the  complexity  of 
the  code  from  the  reuse  library.  This  shall  be  estimated  from  the  time  saved  as  discussed  earlier  in  this  para¬ 
graph.  The  specific  tool  associated  measurements  and  metrics  in  both  time  (person-hours)  and  cost  are  listed 
in  Table  10. 

The  specific  software  associated  measurements  and  metrics  for  VHDL  and  Ada  (or  other  high  level 
language)  are  listed  in  Table  11.  FPGA  “software”  is  included  in  this  category. 

Code  produced  by  automatic  code  generators  will  be  considered  as  belonging  in  the  reuse  category. 
The  “instructions”,  or  flowgraphs,  which  serve  as  inputs  to  the  automatic  code  generators  will  be  considered 
as  original  work. 

The  experience  of  the  people  on  a  project  constitutes  an  element  of  the  reuse  concept.  That  experience 
does  not  alter  the  complexity  of  the  hardware  or  software  which  is  being  implemented  but  it  does  have  an 
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TABLE  10 

Reuse  Measurements  and  Metrics 


Element 

Description 

Original  Implementation 
(time  or  cost) 

Estimated  (time  or  cost)  for  original  design  and  imple¬ 
mentation  (REUSE_ORIG_T,  REUSE_ORIG_C) 

Reuse  evaluation  (time  or 
cost) 

Time  (or  cost)  expended  in  learning  the  capabilities  of 
the  reuse  library  (REUSE_EVAL_T,  REUSE_EVAL_C) 

Reuse  Incorporation  (time  or 
cost) 

Time  (or  cost)  actually  spent  incorporating  element  of 
reuse  library  including  implementation'  (REUSE  T, 
REUSE_C) 

Reuse  Time  Metric  improve¬ 
ment 

original  implementation  time  /  reuse  incorporation  time 
(REUSE_TRATIO) 

Tool  Cost  Metric  improvement 

original  implementation  cost  /  reuse  incorporation  cost 
(REUSE_CRATIO) 

*  The  implementation  must  allow  for  the  fewer  defects  that  would  be  generated  by 
reuse  as  compared  with  an  original  design. 

impact  on  the  process.  Therefore  it  does  enter  the  equation  for  describing  the  complexity  of  the  RASSP  im¬ 
plementation  of  the  system.  A  breadth  of  experience  is  in  the  same  category.  It  is  here  that  a  more  global 
understanding  of  the  project  goals  can  supply  the  feedback  that  is  so  important  to  co-design  which  may  then 
alter  the  distribution  of  resources  or  complexity  in  a  more  optimal  manner.  Metrics  applicable  to  people 
have  been  described  in  Section  4.23.4  and  Section  4.2.5.3. 

4.3. 1.2.2  Interfaces.  These  are,  classically,  an  area  which  contributes  significantly  to  complexity. 
Whether  it  be  the  acquisition  of  data  through  custom  hardware  interfaces  or  the  control  and  coordination  of 
other  functions,  these  interfaces  and  the  disparity  of  elements  passing  through  them  contribute  to  complex¬ 
ity.  The  reuse  function  invoked  by  the  use  of  standards  will  always  be  beneficial  where  they  are  appropriate. 
This  is  not  everywhere.  It  is  possible  to  misuse  standards  through  a  lack  of  understanding  of  the  underlying 
protocols.  Because  good  software  design  breaks  down  a  complicated  problem  into  a  large  number  of  small 
modules,  there  are  a  large  number  of  interfaces  to  contribute  to  complexity.  The  type  of  data  being  transmit¬ 
ted  must  be  the  same  as  the  type  being  received.  This  may  seem  obvious  from  a  hardware  point  of  view  but 
not  all  software  languages  have  supported  this  important  feature  in  the  past.  An  interface  is  between  two 
bodies;  it  should  not  alter  the  data  on  a  different  interface  somewhere  else  in  the  system.  Again,  this  may 
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TABLE  11 

Software  Reuse  Measurements  and  Metrics 


Element 

Description 

Original  (time  or  cost) 

Estimated  (time  or  cost)  for  original  design  and  implementation 
(S_REUSE_0R1G_T,  S_REUSE_ORIG_C) 

Reuse  evaluation  (time  or 
cost) 

Time  (or  cost)  expended  in  learning  the  capabilities  of  the 
reuse  library  (S_REUSE_EVAL_T,  S_REUSE_EVAL_C) 

Reuse  (time  or  cost) 

Time  (or  cost)  actually  spent  incorporating  element  of  reuse 
library  including  implementation*  (S_REUSE_T,  S_REUSE_C) 

Software  Time  Metric 
improvement 

original  implementation  time  /  reuse  incorporation  time 
(S_REUSE_TI) 

Software  Cost  Metric 
improvement 

original  implementation  time  /  reuse  incorporation  time 
(S_REUSE_CI) 

Reuse  code  (percent) 

NCSS  saved  through  reuse  /  NCSS  including  reuse  library 
(S_REUSE_LOC) 

Defect  Density 

Estimated  defects  per  1K  NCSS  (S_REUSE_DEFECT) 

*  The  implementation  must  allow  for  the  fewer  defects  that  would  be  generated  by  re¬ 
use  as  compared  with  an  original  design. 

seem  obvious  from  the  hardware  point  of  view  but  it  has  not  always  been  possible  for  programmers  to  en¬ 
capsulate  the  data  passed  between  tasks.  Modem  languages  and  good  software  engineering  practices  con¬ 
tribute  to  a  minimization  of  complexity.  Interfaces  should  have  a  handshake.  To  ignore  a  handshake  when 
it  is  offered  risks  being  oblivious  to  error  messages  returning  from  other  modules.  Specific  metrics  for 
VHDL  and  Ada  software  are  described  in  Section  4.3.4 .7. 

4.3. 1.2.3  Comprehension.  Comprehension  recognizes  the  limits  of  a  human  being  to  absorb  the  com¬ 
plexity  of  a  problem.  It  is  for  this  very  reason  that  large  problems  are  successively  divided  up  into  pieces 
such  that  the  smallest  piece  can  be  fully  comprehended  by  a  single  person  at  any  point  in  time.  Even  in  small 
teams,  each  individual  has  an  immediate  task  and  a  set  of  interfaces  to  the  team  members.  This  task  may 
change  dynamically  with  the  team  members  over  time  but  never  should  be  left  so  unwieldy  that  it  is  incom¬ 
prehensible.  In  software  it  has  long  been  recognized  that  control  is  more  complex  than  sequential  process¬ 
ing.  The  number  of  “if,  while,  and  for”  statements  in  a  module  is  an  important  measure  of  complexity.  The 
“goto”  statement  has  long  been  out  of  favor  because  of  its  supreme  ability  to  obfuscate  a  simple  program. 
Metrics  applicable  to  this  arena  are  described  in  Section  4.3.4.4.  The  exclusive  use  of  upper  case  is  equally 
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damaging  to  comprehension.  For  over  a  thousand  years  our  language  has  made  use  of  upper  and  lower  case 
to  enhance  our  ability  to  fathom  the  written  page,  only  to  have  been  destroyed  by  the  introduction  of  Fortran 
in  1957.  The  metrics  described  in  4.3.4.2  will  also  be  used  to  evaluate  comprehension.  Modem  program¬ 
ming  practices  and  good  practice  foster  comprehension. 

The  first  generation  of  commercial  array  processors  were  exceptionally  obtuse  in  the  software  depart¬ 
ment,  sometimes  requiring  as  many  as  three  unique  languages  for  all  portions  of  the  processor.  Just  as  hard¬ 
ware  has  improved  and  matured  over  the  years,  so  too  has  the  software.  Today,  a  modem  array  processor 
can  be  programmed  in  a  high  level  language  with  a  compiler.  For  improved  efficiency,  vendors  supply  li¬ 
braries  of  functions  which  may  have  been  hand  coded  in  assembly  language  or  worse.  Writing  microcode 
for  a  pipelined  architecture  stresses  the  limits  of  complexity.  Metrics  applicable  to  microcode  are  described 
in  Section  4.3 .4.8. 

4.3.1.3  Defects.  Defects  are  defined  from  a  customers  point  of  view.  A  deliverable  to  a  customer 
that  is  not  within  specifications  is  considered  to  be  a  defect.  The  customer  may,  in  the  tradition  of  Total  Qual¬ 
ity  Management,  be  internal.  The  customer  may  be  in  the  next  office;  the  customer  may  be  the  same  team, 
working  on  the  next  stage  of  the  product.  Defects  that  occur  during  development,  prior  to  delivery,  are  con¬ 
sidered  private  and  will  not  be  counted  as  defects.  A  hardware  failure,  while  important  from  the  point  of 
view  of  reliability,  is  not  a  RASSP  process  defect,  unless  it  can  be  shown  to  have  arisen  from  a  design  flaw 
such  as  inadequate  cooling.  Within  the  spirit  of  this  definition,  a  declared  limited  functionality  is  not  a  de¬ 
fect.  But  a  delivery  to  a  customer  must  function  correctly  within  the  declared  scope  of  that  delivery.  This 
definition  is  in  concert  with  the  spiral  model.  A  change  in  requirements  is  not  a  defect.  Defects  are  not  sim¬ 
ple  black  or  white  objects,  they  are  complex  elements  which  must  be  understood  in  the  overall  context  of 
the  project.  Defects  implicitly  receive  weighting  factors  which  are  a  function  of  the  time  and  space  in  which 
the  defect  seems  to  be  located.  Defects  which  are  caught  early  in  the  process  have  little  weight,  while  those 
not  caught  until  equipment  is  in  the  field  have  a  ponderous  weight.  Defects  which  have  a  small  sphere  of 
influence  also  have  little  weight,  while  those  which  have  ramifications  far  removed  from  their  own  location 
are  weighted  more.  The  time  in  the  benchmark  cycle  when  a  defect  is  identified  (DEFECT_FIND)  shall  be 
reported  with  the  Developer’s  measurement  or  estimate  of  the  time  (person-hours)  required  for  correction. 
The  fundamental  source  of  the  defect  shall  also  be  reported  (DEFECT_SRC).  The  measurements  and  met¬ 
rics  for  tool  defects  shall  be  reported  as  described  in  Table  12. 

4.3.1.4  Requirements  TYaceability.  It  is  important  to  know  that  a  design  element  responds  to 
some  requirement  and  that  every  requirement  has  been  addressed  by  at  least  one  design  element.  Testing 
may  produce  changes  in  any  of  these  elements  and  the  relationships  between  the  requirements  and  the  de¬ 
sign  elements  must  stUl  exist.  There  are  five  general  areas  in  the  implementation  of  the  requirements.  These 
are:  requirements,  design,  implementation,  tests,  and  changes.  The  implementation  may  be  hardware  or 
software,  whether  the  latter  be  VHDL  or  Ada  or  C  code.  A  partial  list,  as  an  example  only,  of  the  document 
types  that  are  produced  is  given  in  Table  13. 

Documents  normally  contain  data  only  of  the  same  kind,  e.g.,  the  requirements  specification  docu¬ 
ment  contains  the  requirements  data  for  the  implementation.  This  packaging  is  quite  natural  since  sunilar 
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TABLE  12 

Tool  Defect  Measurements  and  Metric 


Element 

Description 

Fix  time  (and  cost) 

Time  (and  cost)  consumed  in  fixing  defect*  after  existence 
was  recognized  (DEFECT_UNDO_T,  DEFECT_UNDO_C) 

Lost  time  (and  cost) 

Estimated  time  lost  because  defect  existed 
(DEFECT_LOST_T,  DEFECT_LOST_C) 

Lost  capability  metric  (percent) 

Increase  in  ‘lime  to  markef  or  IOC  as  a  percent  of  bench¬ 
mark  life  span  (DEFECT_TTM) 

*  A  defect  is  not  simply  a  bug  in  the  program,  an  invalid  modeling  of  a  simulation  is  also 
a  defect. 

TABLE  13 

Partial  List  of  Document  Types 

Document  Type 

Requirements  Specification 
Software  Design  Document 
VHDL  Design  Language  File 
Source  Code 
VHDL  Test  Description 
VHDL  Test  Results 
User’s  Manual 

Project  Development  Schedule 
Software  Problem  Report  Database 
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data  are  normally  created  together  at  the  same  time  by  the  development  team.  However,  this  packaging 
scheme  fails  to  capture  important  relationships  between  engineering  data  of  different  kinds.  This  scheme 
will  not  assist  the  development  team  in  tracing  how  any  particular  requirement  is  allocated  to  specific  design 
elements  or  how  these  design  elements  are  implemented  by  the  VHDL  or  Ada  code  elements.  The  metric 
associated  with  requirements  traceability  for  the  documentation  generated  by  each  tool  shall  be  calculated 
based  on  Table  14. 


TABLE  14 

Requirements  Traceability  Metric  (REQ_TRAC) 


Level 

Characteristic 

0 

Completely  manual  process;  documents  not  under  a  version  control  system;  no 
links  between  documents 

1 

TBD 

2 

Some  documents  under  version  control;  some  links  may  exists  between  docu¬ 
ments  in  different  areas 

3 

TBD 

4 

Full  hypertext  documentation  with  anchors  and  links  between  all  five  areas. 
Interactive  navigation  of  the  linked  elements.  Complete  backannotation 
between  tools,  support  for  concurrent  processes.  Full  configuration  control 

4J.1.5  Measurements.  At  the  start,  the  most  important  element  in  calculating  metrics  will  be  an 
acceptance  of  the  need  for  the  measurements.  This  is  part  of  the  total  quality  management.  Without  a  com¬ 
mitment  on  all  levels,  it  cannot  be  successful.  It  must  be  recognized  and  accepted  by  management  that  the 
collection  of  measurements  is  an  important  part  of  this  program.  It  must  be  accepted  by,  and  passed  down 
from,  management.  Measurements  are  not  collected  at  the  end  of  the  project,  they  are  part  of  a  continuous 
process  which  enables  trend  data  to  be  made  available. 

4.3.2  Application  Complexity  Metrics 

Application  complexity  metrics  focus  principally  on  the  products  or  applications  developed  with 
RASSP,  and  are  viewed  as  a  means  of  normalizing  different  benchmarks  so  that  comparisons  of  the  RASSP 
process  over  time  and  over  different  applications  can  be  made. 
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Application  requirement  complexity  metrics  (ARCMs)  endeavor  to  capture  the  inherent  complexity 
of  a  given  benchmark  application,  independent  of  the  particular  hardware  and  software  implementation.  The 
ARCMs  form  the  basis  for  comparing  the  difficulty  of  successive  benchmarks.  The  ARCMs  will  also  serve 
as  a  reference  for  determining  efficiency  of  the  hardware  and  software  realizations  of  a  benchmark  produced 
by  the  Developer. 

ARCMs  consist  of  three  components:  apphcation  requirements,  external  constraints,  and  “ility”  re¬ 
quirements.  The  following  ARCMs  shall  be  computed  by  the  Developer  with  reference  to  the  processor  re¬ 
quirements  of  Section  2  and  the  executable  requirements  of  Section  3. 

4.3.2.1  Application  Requirements.  The  complexity  of  any  embedded  signal  processor  is  deter¬ 
mined  by  the  inherent  complexity  of  the  application  being  implemented.  The  complexity  of  the  application 
is  determined  by  its  function,  computational  requirements,  control  flow,  external  interfaces,  and  dynamic 
range  or  precision. 

To  determine  functional  complexity,  the  total  number  of  system  operations  required  per  output  datum 
shall  be  recorded  (TOTSYSOP).  A  system  operation  is  any  uniquely  defined  mathematical  operation  on  one 
or  two  input  variables  that  generates  a  single  output.  Straightforward  mappings  of  single  variables,  such  as 
trigonometric  functions,  logarithms,  and  exponentials  are  considered  systems  operations.  The  Fourier  trans¬ 
form  is  a  mapping  and,  thus,  is  also  a  system  operator.  Well-defined  algebraic  operators  between  two  vari¬ 
ables  including  inner  products,  vector  multiplies,  dot-products,  and  cross-products  are  also  considered 
system  operators. 

Convolution  is  a  moving  inner-product  and  is  therefore  more  complex  than  a  system  operator.  How¬ 
ever,  convolution  is  based  on  a  unique  system  operator  (i.e.,  the  inner-product)  applied  in  a  series  of  similar 
operations.  Such  re-use  of  system  operations  reduces  the  complexity  of  the  application  process.  Thus,  the 
number  of  unique  system  operators  per  output  datum  shall  be  recorded  (UNISYSOP).  Operators  are  con¬ 
sidered  to  be  re-used  if  they  act  on  similar  data.  For  instance,  equalization  weighting  of  data  of  different 
polarization  are  similar,  but  equalization  weighting  is  not  similar  to  kernel  multiplication  in  azimuth  com¬ 
pression  (see  Section  2.1).  The  maximum  number  of  system  operations  per  unit  time  (SYSOPS)  shall  also 
be  recorded. 

Computational  requirement  is  a  measure  of  the  computation  required  per  second  for  arithmetic  and 
logical  operations.  For  arithmetic  operations  both  primitive  and  composite  operations  are  defined.  Primitive 
operations  are  multiply,  add,  subtract,  compare,  shift,  etc.  and  no  distinction  is  made  between  integer  and 
real  operations  or  single  and  double  precision.  If  there  are  a  significant  number  of  complicated  primitives, 
such  as  divide,  they  should  be  accounted  for  as  an  equivalent  number  of  primitive  operations.  The  PROPS 
metric  is  given  in  primitive  operations  per  second.  It  is  understood  that  this  metric  is  dependent  on  the  as¬ 
sumed  implementation  of  the  algorithm  and  is  meaningful  only  with  an  explanation  of  the  assumed  imple¬ 
mentation.  A  composite  operation  is  an  operation  on  one  or  more  sets  of  data  which  produces  another  set, 
such  as  a  Fourier  transform,  vector  multiply,  etc.  UNICOMOP  is  the  number  of  unique  composite  opera¬ 
tions  in  the  assumed  implementation  and  COMOPS  is  the  number  of  primitive  operations  per  second  which 
are  accounted  for  by  composite  operations.  (COMOPS  will  be  a  subset  of  PROPS.) 

Control  flow  (CONFLOW)  complexity  is  a  measure  of  the  number  of  user  commanded  modes  of  op¬ 
eration  and  degree  of  data  dependent  branching.  It  is  rated  Low,  Medium  or  High. 
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The  maximum  number  of  system  data,  including  constants,  coefficients,  etc.,  required  to  be  resident 
within  the  application  process  at  any  time  shall  be  recorded  (SYSRES).  Datum  types  (e.g.,  frequency  sam¬ 
ples,  range  pulses,  images)  vary  within  the  application  process,  so  that  SYSRES  is  a  count  of  mixed  datum 
types.  In  addition,  DATARES  is  the  maximum  amount  of  data  required  to  be  resident  in  the  process  as  mea¬ 
sured  in  bytes.  No  distinctions  are  made  as  to  where  the  data  may  reside  in  a  possible  storage  hierarchy. 

To  determine  the  complexity  of  external  interfaces,  the  total  number  of  external  interfaces  shall  be 
recorded  (TOTEX'llNT),  together  with  the  number  and  type  of  unique  (UNIEXTINT)  and  non-standard  in¬ 
terfaces  (NSTDEXriNT).  Average  and  peak  data  rates  shall  be  recorded  for  all  process  input  and  output 
data  (AVGIN,  PKIN,  AVGOUT,  PKOUT).  The  number  of  input  sources  (INSOU)  and  output  (OUTDES) 
destination  of  process  data  shall  be  recorded  together  with  the  maximum  allowable  response  latencies  (LA¬ 
TENT). 

The  required  dynamic  range  (DYNAMIC)  and  precision  (PRECIS)  of  both  processor  input  and  out¬ 
put  data  shall  also  be  recorded. 

4.3.2^  External  Constraints.  External  constraints  affects  the  complexity  of  embedded  signal  pro¬ 
cessors.  Such  constraints  include  the  physical  constraints  imposed  by  the  system  into  which  the  processor 
is  imbedded,  as  well  as  environmental  and  cost  constraints  and  imposed  mil-standards. 

The  physical  constraints  of  the  processor  shall  be  recorded.  This  shall  include  maximum  allowable 
size  (MAXSIZE)  and  weight  (MAXWGT),  maximum  allowable  values  of  peak  and  average  power  (MAX- 
PKPOW,  MAXAVGPOW),  and  the  source  of  prime  power  (PRMPOW);  e.g.,  IIOVAC,  28VDC,  etc. 

The  environmental  constraints  of  the  processor  shall  be  recorded.  This  shall  include  the  allowable 
ranges  for  temperature,  humidity,  altitude,  corrosion  resistance,  and  shock  and  vibration  (TEMP,  HUMID, 
ALT,  CORRES,  SHOCK).  Allowable  values  of  all  constraints  for  both  operational  use  and  storage  shall  be 
recorded. 

All  cost  constraints  shall  be  recorded.  This  includes  total  cost  (TOTCOST)  as  well  as  non-recurring 
engineering  costs  (NRECOST). 

All  required  mil-standards  shall  be  recorded  as  well  as  any  modifications,  tailoring,  or  exemptions  to 
required  standards. 

4.3.2.3  Dity  Requirements.  Requirements  for  testability,  reliability,  and  maintainability  increase 
the  complexity  of  the  embedded  signal  processor.  The  required  degree  of  fault  coverage  shall  be  recorded 
(FLTCOV)  together  with  the  maximum  allowable  latency  in  detecting  faults  (FLTLAT)  and  the  required  lev¬ 
el  of  fault  isolation  (FLTISO).  The  maximum  allowable  fault  rate  (MAXFLTRT)  shall  be  recorded  together 
with  the  maximum  allowable  time  for  fault  recovery  (MAXFLTREC).  The  skill  level  required  for  mainte¬ 
nance  personnel  shall  be  recorded  (SETLL)  as  will  the  required  level  of  documentation  (DOC). 
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4.3.3  Hardware  Products 


The  primaiy  concern  of  the  hardware  metrics  is  the  RASSP  product.  Hardware  performance  metrics 
measure  the  performance  of  the  processor  and  they  mirror  the  application  process  requirements  metrics  of 
Section  4.3.2. 1.  Hardware  complexity  metrics  measure  characteristics  of  the  hardware  implementation. 

4.3.3.1  Hardware  Performance  Metrics.  In  Benchmark-2,  the  Developers  shall  provide  measure¬ 
ments  for  the  following  metrics. 

4.3.3. 1.1  Execution  Rate.  The  execution  rate  realized  in  primitive  operations  per  second  (as  defined 
in  Section  4.3 .2.1)  while  executing  the  Benchmark  application  shall  be  reported  as  PROPS.  If  the  processor 
can  operate  in  several  different  modes  then  PROPS  shall  be  reported  for  the  each  mode.  If  the  entire  pro¬ 
cessor  can  support  a  higher  throughput  than  required  by  the  application  then  the  maximum  possible  rate 
shall  be  reported  as  MPROPS.  The  subsystem  or  interface  which  determines  this  maximum  shall  be  de¬ 
scribed. 

4.3.3. 1.2  I/O  and  Dynamic  Range.  The  peak  and  sustained  data  transfer  rate  and  the  data  representa¬ 
tion  format  at  each  system  interface  shall  be  reported.  The  dynamic  range  supported  in  the  processing  cir¬ 
cuits  shall  be  reported. 

4.3. 3. 1.3  Power.  Peak  power  (PKPOW)  and  average  power  (AVGPOW)  when  operating  at  the  rate  for 
which  PROPS  is  reported. 

4.3.3. 1.4  Size  and  Weight.  The  dimensions  of  the  system  box(es)  and  their  weight. 

4.3.3. 1.5  Cost.  Both  real  costs  of  the  prototype  and  projected  manufacturing  costs  are  desired.  Proto¬ 
type  costs  shall  include  die  total  small-quantity  cost  of  all  components  in  the  system  and  NRE  incurred.  The 
estimate  of  production  cost  for  producing  N  units  over  a  period  of  Y  years  shall  include  component,  NRE, 
manufacrnring,  testing  and  documentation  costs.  Unit  Life  Cycle  cost  for  an  assumed  total  number  of  N 
units  over  a  period  of  LC  years  shall  be  reported. 

4.3. 3. 1.6  Testability.  The  level  of  conformance  to  testability  specifications  as  well  as  any  additional 
capability  added  by  the  developer  shall  be  described.  The  data  may  represent  both  estimates  and  results  of 
experiments  and  shall  include:  time  to  execute  routine  diagnostics,  test  coverage,  level  of  fault  isolation  and 
mean  time  to  detect  faults. 

4.3.3.1. 7  Reliability/Availability.  The  level  of  adherence  to  reliability/availability  specifications  shall 
be  described.  Data  to  be  presented  includes  predicted  mean  time  to  failure  and  time  to  recover  from  or  repair 
a  fault. 

4. 3. 3. 1.8  Environment.  For  both  operational  and  storage  environments  the  design  goals  and  measure¬ 
ment  results  for  temperature,  altitude,  humidity,  and  shock  and  vibration  resistance  shall  be  reported. 

4.3.3.2  Hardware  Complexity  Metrics.  Hardware  Complexity  Metrics  (HCM)  capture  the  com¬ 
plexity  of  the  benchmark  application  hardware  through  measures  of  degree  of  integration,  COTS  vs.  cus¬ 
tom,  number  of  elements,  clock  rate,  etc.  They  also  give  a  measure  of  the  level  of  technology  employed. 
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•  Size  Storage;  For  each  of  the  storage  levels;  cache  (off  processor-chip),  main  and  second 
level,  report  the  total  number  of  bytes  of  storage. 

•  Gates;  For  the  sum  of  all  ICs  comprising  COTS  MSI  devices,  FPGAs  and  custom  ICs  give 
the  total  number  of  gates  in  some  well  defined  manner  (e.g.  and-gate  equivalents). 

•  VLSI;  Identify  and  report  number  used  of  all  non-memory  ICs  not  included  in  above  gate 
count,  i.e.  processors  and  other  function-specific  circuits. 

•  Technology  Speed;  Report  the  clock  rate  of  the  system  and  identify  any  asynchronous  cir¬ 
cuits  and  interfaces.  Identify  any  circuits  which  use  higher-speed  internal  clocks. 

•  IC;  Identify  all  circuit  technologies  used,  e.g.  CMOS,  ECL,  GaAs. 

•  Buses;  Identify  all  internal  system  buses,  their  size,  protocol  and  peak  and  average  data 
transfer  rate  in  this  application. 

•  Implementation  style:  List  each  unique  circuit  and  the  number  used  in  the  following 
classes  of  circuits:  COTS,  FPGA,  gate  array,  standard  cell  and  full  custom. 

•  Packaging  Levels:  Identify  and  describe  the  levels  of  packaging.  For  example:  wirewrap 
backplane,  PCB  pluggable  module  with  surface  mount  devices,  thin  film  MCM  with  ball 
grid  array  chips,  ICs  with  various  packages. 

•  Density:  For  the  most  dense  module  at  the  circuit  board  and  MCM  levels  give  the  number 
of  nets  and  total  number  of  pins.  For  the  three  ICs  with  largest  number  of  pins  describe  the 
package  technology. 

•  Heat:  For  the  highest  dissipation  IC  give  the  expected  maximum  junction  temperature 
under  the  most  severe  operating  condition  specified  in  the  benchmark. 

•  Interfaces;  Identify  and  describe  system  interfaces. 

4.3.4  Software  Products 

Maintainability  of  software  refers  to  the  ease  with  which  it  can  be  understood,  corrected,  adapted, 
and  enhanced.  Although  considered  mainly  for  source  code,  it  is  also  relevant  for  specification  and  design 
documents,  and  test  plan  documents.  We  can  define  three  types  of  maintenance: 

Corrective:  bug  finding  and  fixing 

Adaptive:  modifying  software  to  properly  interface  with  a  changing  environment 

Enhancements:  adding  new  functionally  to  a  working,  successful  piece  of  software 
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Maintainability  is  an  external  attribute  which  correlates  well  with  certain  internal,  and  therefore  more 
easily  measurable,  attributes.  These  internal  attributes  attempt  to  measure  characteristics  of  the  software  en¬ 
vironment  and  the  source  code  itself  in  the  three  major  areas  that  were  defined  for  software  complexity. 

In  the  area  of  comprehension,  we  have  the  classical  measures  of  complexity  such  as  the  well  known 
McCabe’s  Cyclomatic  Complexity  measure.  This,  and  its  variations,  are  useful  metrics  but  any  single  metric 
can  be  distorted.  We  have  found  examples  where  three  independent  software  tools  for  measuring  Cyclomat¬ 
ic  Complexity  yielded  two  different  values  for  the  same  module.  The  definition  adapted  for  RASSP  is  in 


accordance  with  the  IEEE  Standard, 

P 

number  of  control  paths  into  the  program 

E 

= 

number  of  edges  (transfers  of  control) 

N 

= 

number  of  nodes 

Cyclomatic  Complexity 

= 

E-N-I-2P 

Or,  alternately,  count  the  number  of  nodes  in  the  flowgraph  with  two  or  more  paths  leading  out  from  the 
node.  The  Cyclomatic  Complexity  value  is  that  count  plus  one  [3]  The  Cyclomatic  Complexity  metric  is 
specified  in  Section  4.3 .4.4. 

4.3.4.1  Lines  of  Code.  The  number  of  modules  in  a  project  and  the  size  of  a  module  contribute  to 
complexity.  Size,  as  it  impacts  comprehension,  is  influenced  more  by  the  number  of  executable  statements 
within  the  module  than  by  the  total  amount  of  paper  consumed.  For  this  reason,  when  counting  lines  of 
code,  count  only  executable  lines  of  code  as  compared  to  the  frequently  seen  “non  comment  source 
statements”.  This  does  not  mean  that  comments,  white  space,  and  non-executable  statements  are  not 
counted,  for  they  are.  Style  is  an  equally  important  attribute. 

There  are  two  variations  of  the  “lines  of  code”  metric  which  shall  be  measured  by  the  Developers  for 
each  module  and  for  all  languages  used  in  the  benchmark.  The  first  is  the  usual  non-comment  source  state¬ 
ments  which  will  be  measured  in  a  manner  to  be  consistent  with  the  COCOMO  models  (LOC_COCO). 
The  second  measure  will  be  restricted  to  executable  lines  only  (LOC_EXEC).  This  does  not  include 
parameter  definitions,  type  definition  statements,  or  braces  on  a  single  line.  As  spreads  of  up  to  30%  within 
the  definition  have  been  experienced,  the  specific  implementation  for  coimting  “lines  of  code”  must  not 
change,  for  a  given  language,  during  the  course  of  the  RASSP  program.  The  average  number  of  executable 
lines  of  code  per  module  (LOC_AVG),  the  median  (LOC_MED),  and  the  maximum  (LOC_MAX)  shall 
also  be  computed  as  a  metric.  Any  module  having  a  number  greater  than  that  permitted  by  the  style  manual 
and  not  in  a  category  permitted  by  the  style  manual  (e.g.,  case  statements)  shall  be  considered  defective. 
During  the  course  of  the  benchmark,  a  weekly  count  of  lines  of  code  shall  be  maintained  for  all  software 
developed  as  part  of  the  benchmark  in  the  categories  listed  in  Table  15  below. 

The  lines  of  code  produced  by  automatic  code  generators  shall  be  measured  consistent  with  Section 
4.3. 1.2.1  and  must  be  identified  separately  as  having  been  produced  by  this  method.  At  this  higher  level  of 
abstraction,  it  is  still  required  to  measure  the  fundamental  productivity  of  people,  rather  than  the  secondary 
measurements  produced  by  the  code  generators.  The  Developer  shall  recommend  techniques  for  measuring 
the  inherent  productivity  of  people  when  using  these  code  generators.  Where  applicable,  the  Developer  shall 
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TABLE  15 


Lines  of  Code  Categories 


Category 

Lines  of  Code 

Released,  excl.  test  bench 

Released,  test  bench 

All  original  development 

Reuse  library 

count,  separately,  the  blocks  and  interconnecting  lines  on  flowgraphs  where  these  are  used  as  inputs  to  the 
code  generators. 

43,4.2  Style.  For  each  of  the  languages  used  in  the  benchmark  (e.  g.,  Ada,  VHDL,  FPGA)  a  style 
manual  existence  metric  (STYLE_EXIST)  with  a  value  of  zero  if  the  manual  does  not  exist,  and  1  otherwise 
shall  be  reported.  Software  must  have  a  set  of  uniform  standards  for  style;  if  it  does  not,  complexity  increas¬ 
es  and  comprehension  suffers.  The  style  manual  defines  a  uniform  and  consistent  set  of  practices  so  that 
each  module  in  a  program  appears  to  have  been  written  by  the  same  person.  Table  16  lists  the  levels  assigned 
to  the  style  metric  (STYLE). 

Style  also  encompasses  good  programming  practice.  For  example,  the  style  guide  may  expect  that  an 
error  return  from  a  module  is  always  checked,  even  though  the  resulting  “if’  test  will  increase  the  resulting 
complexity  value.  In  this  case,  the  importance  of  the  correct  style  overrides  the  increase  in  complexity.  This 
also  serves  to  demonstrate  an  example  of  the  misuse  of  automatic  tools  to  make  decisions  without  regard  to 
human  factors.  Two  modules  with  the  same  computed  complexity  could  have  vastly  different  logic  struc- 
mre.  Consider  a  module  such  as  shown  in  Figure  8  containing  a  clear  sequence  of  submodules,  each  with 
an  error  return  being  checked  according  to  good  programming  practice.  Compare  this  with  the  contorted 
logic  of  the  module  in  Figure  9  which  has  the  same  complexity  value. 

There  will  be  two  metrics  associated  with  style.  The  first  will  be  based  on  the  existence  of  a  style  man¬ 
ual  and  its  content.  For  the  second,  the  Developer  shall  conduct  an  evaluation  of  all  application  software 
produced  on  the  benchmark  according  to  the  levels  (0=bad)  to  (3=good)  in  the  preceding  table. 
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Level 

Characteristic 

0 

Incomprehensible,  each  module  could  have  been  written  by  a  different  person; 
lack  of  white  space  and  comments;  lack  of  include  files;  use  of  embedded  con- 

stants,  etc.  Lack  of  ANSI  standards.  Random  variable  naming. 

1 

Complex-,  remnants  of  all  or  most  of  the  above 

2 

Moderate:  use  of  include  files,  no  embedded  constants,  nonuniform  overall 
style 

3 

Easily  comprehended.  Uniform  and  consistent  generally  accepted  practices 
according  to  a  uniform,  documented  style  guide  consistent  with  the  language. 
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Figure  9.  Complex  module  flowchart. 

4.3.4.3  Change  Control.  A  revision  control  system  is  also  an  important  element  to  reducing  com¬ 
plexity  and  improving  comprehension.  These  track  a  software  system  through  its  mature  lifetime  so  that  old 
versions  can  be  retrieved  and  the  changes  to  new  versions  documented.  Table  17  lists  levels  assigned  to  the 
metric  for  the  software  revision  control  (CNFG_MGT). 

The  Developers  shall  evaluate  all  application  software  produced  under  the  benchmark  according  to 
the  scale  of  (0=bad)  to  (3=good).  This  metric  (CNFG_MGT)  shall  be  applied  to  all  software. 
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TABLE  17 


Metric  for  Software  Revision  Control 


Level 

Characteristic 

0 

Chaotic,  source  may  not  match  binary;  control  by  verbal  agreement 

amongst  the  team 

1 

Primitive:  Source  Code  Control  System,  for  instance 

2 

Moderate.  Revision  Control  System  or  other  second  generation  system 

3 

Modem:  Integrated  with  Edit,  Compile,  Debug  environment 

4.3.4.4  Code  Metrics.  The  Developers  shall  compute  the  Halstead^  (Table  18)  and  McCabe 
(MCCABE_CCN)  metrics,  as  defined  in  IEEE  Standard  1061-1992  (Section  4.3.4),  on  all  benchmark 
source  code.  In  addition,  the  McCabe  metric  shall  be  computed  on  all  flow  diagrams  generated  as  part  of 
the  software  design  process. 

The  control  flow  diagrann  of  a  module  forms  the  basis  of  many  complexity  measures  including  the 
McCabe  metric  previously  mentioned.  This  was  one  of  the  first  complexity  metrics  and  has  considerable 
importance.  There  have  been  some  validation  studies  and  the  results  could  fairly  be  described  as  mixed. 
Nevertheless,  this  metric  has  been  used  to  good  effect.  Another  metric  in  this  category  is  that  of  tree  impurity 
defined  by  Fenton  [2].  His  metric  (FENTON)  can  be  reduced  to  the  equation 

2  (g  —  w  +  1) 

(n-l)(n-2)’ 

where  e  is  the  number  of  edges  of  the  graph  and  n  is  the  number  of  nodes.  Other  metrics  have  been  found 
that,  while  interesting,  tend  to  measure  the  deleterious  impact  of  the  now  prohibited  “goto”  statement.  We 
wiU  evaluate  these  options  especially  as  available  integrated  into  commercial  products  for  the  RASSP  pro¬ 
gram.  A  useful  source  of  program  metrics  based  on  the  theory  of  flow  diagrams  and  Fenton’s  work  is  avail¬ 
able  from  the  Centre  for  Systems  and  Software  Engineering  at  South  Bank  University,  London,  but  does 
not  currently  support  the  Ada  language. 


3.  The  Halstead  metric  is  not  required  for  VHDL  code  (Section  4.3.4.9). 
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TABLE  18 
Halstead  Metrics 


Symbol 

Halstead  Description 

n1 

number  of  distinct  operators  in  a  program  {HAL_N_OPTOR)) 

n2 

number  of  distinct  operands  in  a  program  (HAL_N_OPAND) 

N1 

number  of  occurrences  of  operators  in  a  program 
(HAL_N_OCC_R) 

N2 

number  of  occurrences  of  operands  in  a  program 
(HAL_N_OCC_D) 

n 

program  vocabulary  (HAL_VOCAB) 

N 

observed  program  length  {HAL_OB_LEN) 

L 

estimated  program  length  (HAL_ES_LEN) 

V 

program  volume  (HAL_VOL) 

D 

program  difficulty  (HAL_DIFF) 

For  all  VHDL  code  produced  on  this  benchmark,  the  six  code  metrics  described  in  Table  19  which  are 
unique  to  this  language,  shall  be  computed.  We  have  found  no  commercial  or  public  domain  tools  to  auto¬ 
matically  compute  the  McCabe  metric  for  the  VHDL  language.  Instead,  a  flowgraph  is  manually  con- 
stmcted  and  the  number  of  nodes  with  more  than  one  path  exiting  from  it  are  counted.  The  McCabe 
cyclomatic  complexity  metric  is  one  more  than  the  value  measured  from  that  procedure.  Constructing 
flowgraphs  is  arguably  a  good  software  design  procedure,  so  this  should  not  be  an  imposition  upon  a 
Developer. 


4.3.4.5  Code  Defects.  Software  baselines  shall  be  generated  during  the  course  of  the  benchmark 
at  4-6  week  intervals.  A  “baseline”  shall  be  considered  as  code  that  has  been  “released”  within  the  context 
of  the  definition  of  defects  in  Section  4.3. 1.3.  Module  differences  between  successive  baselines  shall  be 
evaluated  by  the  Developer  for  difterences  not  attributable  to  an  intended  expanded  capability  or  to  a  change 
in  requirements.  Such  changes  shall  be  considered  as  defects.  For  code  defects,  this  shall  be  evaluated  and 
categorized  according  to  Table  20  below. 
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TABLE  19 
VHDL  Code  Metrics 


Metric 

Description 

Concurrency 

Number  of  concurrent  statements  in  an  architecture  (V_CONCURRENCY).  For 
a  behavioral  architecture,  this  may  be  the  number  of  “process”  statements. 

Signals  in  use 

Number  of  signals  in  each  architecture,  process,  etc.  (V^SIGNALS) 

“Access” 

All  uses  of  this  type  in  any  architecture,  function,  procedure,  etc.  (V_ACCESS). 
Measures  the  propensity  of  the  author  or  designer  for  “pointer”  types. 

Abstraction  levels 

Number  of  different  types  of  architectures  per  entity  (V_ABSLEV).  This  may  be 
one  when  only  behavioral  modeling  is  done,  but  should  increase  as  the  fidelity 
of  the  design  progresses.  This  assumes  the  same  test  bench  remains  in  use. 

Complexity  of 
structures 

Number  of  hierarchial  uses  of  “record”  types  or  “array”  types 
(V_STRUCTURES).  This  measures  attempts  to  trade  off  code  complexity 
against  unintelligible  structures. 

TABLE  20 

Causes  of  Code  Defects 


Defect  Category 

Number  of  Defects 

Specifications  (D_SPEC) 

Logic  (D_LOGIC) 

User  Interface  (D_UI) 

Error  Checking  (D_EC) 

HW  Interface  (D_HWI) 

SW  Interface  (D_SWI) 

Data  Handling  (D_DH) 

Standards  (D_STD) 
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Software  testing  often  attempts  to  cover  all  paths  through  the  code  by  branch  loop  testing.  It  is  not 
uncommon  that  software  works  “by  accident.”  Each  code  defect  shall  be  evaluated  by  the  Developer  to 
ascertain  the  type  of  testing  required  to  have  detected  the  defect  prior  to  release  of  the  software 
(DEFECT_TST).  At  the  end  of  the  benchmark  the  Developer  shall  estimate  the  number  of  defects 
(DEFECT_RES)  remaining  in  the  software,  but  yet  undetected,  based  on  the  observed  defect  density  and 
other  prior  experience.  The  Developer  shall  create  a  weekly  trend  chart  giving  the  defects  found  per  100 
hours  of  test  for  the  system  software.  The  Developer  shall  evaluate  testing  efficiency  according  to  Table  21 
below. 


TABLE  21 


Code  Testing  Efficiency 


Testing  Type 

Efficiency 

(Defects  Found  per  Hour) 

Regular  use 

Black  box 

White  box 

Readi  ng/l  nspections 
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4.3.4.6  Cohesion.  Cohesion  is  an  attribute  of  individual  modules,  describing  the  extent  to  which 
their  elements  are  needed  to  perform  the  same  task.  Table  22  lists  the  classes  of  cohesion  which  form  the 
scale  of  measurement. 


TABLE  22 
Cohesion  Metric 


Level 

Characteristic 

0 

Coincidentat  module  performs  more  than  one  function,  and  these  are 
totally  unrelated 

1 

Temporal:  module  performs  more  than  one  function,  and  these  are  only 
related  by  the  fact  that  they  must  occur  within  the  same  time  span 

2 

Communicational:  more  than  one  function,  but  all  on  the  same  body  of 
data 

3 

Sequentiat.  module  performs  more  than  one  function,  but  these  occur 
in  an  order  which  is  described  in  the  specification 

4 

Functional-,  module  performs  a  single  well  defined  function 

The  Developers  shall  evaluate  all  modules  in  the  benchmark  application  software  according  to  the 
scale  of  (0=bad)  to  (4=good)  and  generate  the  probability  distribution  (SCOHE_PD)  associated  with  this 
data.The  metrics  shall  be  the  mean,  median,  and  peak  of  the  corresponding  probability  distribution 
(SCOHE„AVG,  SCOHE_MED,  and  SCOHE_MAX). 

4.3.4.7  Interfaces.  The  interfaces  have  always  been  an  area  of  complexity.  While  modem  software 

tools  prevent  mis-typing  across  interfaces,  they  cannot  alter  the  number  of  interfaces  or  the  coupling  in  the 
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interfaces.  Coupling  is  a  measure  of  the  degree  of  interdependence  between  modules.  Table  23  lists  some 
well  established  empirical  relations  about  coupling  which  give  the  scale  of  measurement. 


TABLE  23 
Interface  Metric 


Level 

Characteristic 

0 

Content  a  module  branches  into,  changes  data,  or  alters  a  statement 
in  another  module 

1 

Common:  modules  sharing  the  same  global  data 

2 

Control:  a  module  passes  a  parameter  to  another  with  the  intent  of 
controlling  its  behavior 

3 

Data:  modules  communicate  by  scalar  or  vector  data  items  which  do 
not  incorporate  any  type  of  control;  this  type  of  coupling  is  necessary 
for  any  communication  between  modules 

4 

None:  totally  independent 

The  Developers  shall  evaluate  all  pairwise  modules  in  the  benchmark  application  software  according 
to  the  scale  of  (0=bad)  to  (4=good)  and  generate  the  probability  distribution  (SINTERF_PD)  associated 
with  this  data.The  metrics  shall  be  the  mean,  median,  and  peak  of  the  corresponding  probability  distribution 
(SINTERF_AVG,  SINTERF_MED,  and  SINTERF_MAX). 

4.3.4.8  Microcode.  The  early  generations  of  array  processors  were  programmed  exclusively  in  mi¬ 
crocode.  Just  as  progress  in  hardware  has  improved  performance  over  the  years,  so  also  has  the  software  for 
this  type  of  processor.  By  the  second  generation,  array  processors  could  be  programmed  in  a  high  level  lan¬ 
guage  resembling  Fortran  with  special  features  to  implement  such  things  as  synchronization  of  a  double 
buffered  cache  with  main  memory.  Attempts,  at  various  levels  of  success,  were  made  to  hide  the  esoterics 
of  the  microcode  from  the  programmer  through  the  extensive  use  of  libraries.  In  the  current  generation,  this 
has  been  carried  one  step  further  with  the  use  of  standard  C  or  Ada  code,  still  using  extensive  library  mod¬ 
ules,  and  less  proprietary  styles  in  making  use  of  fundamental  hardware  architecture  features.  Today,  when 
a  specific  application  segment  of  the  processing  is  not  in  the  library,  it  can  be  left  in  the  high  level  language 
and  used  as  a  compiled  function  if  processing  time  constraints  permit.  Microcode  modules  which  are  to  be 
added  to  the  reuse  library  need  to  be  thoroughly  tested  for  they  cannot  be  reexamined  in  the  future  as  easily 
as  modules  written  in  a  high  level  language.  This  is  true  from  both  a  data  processing  point  of  view  and  a 
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control  point  of  view.  In  the  latter,  for  example,  if  a  module  is  sloppy  in  reading  beyond  the  input  vector 
address  boundaries,  then  the  consequences  may  be  catastrophic  if  the  operating  system  were  to  be  enhanced 
or  if  new  versions  of  the  processor  chip  were  implemented  using  memory  management  functions.  Each  mi¬ 
crocode  module  developed  for  the  benchmark  shall  be  evaluated  according  to  the  metric  defined  in  Table  24. 


TABLE  24 

Microcode  Metric  (MICRO) 


Value 

Characteristic 

0 

Module  should  have  been  written  in  a  HLL.  Extensive  data 
dependencies 

1 

TBD 

2 

All  paths  checked,  some  data  dependencies 

3 

TBD 

4 

No  data  dependencies,  all  paths  through  the  module  verified, 
communicational  interfaces  only 

Microcode  modules  which  are  generated  as  part  of  the  benchmark  application  software  will  be  subject 
to  the  same  metrics  as  any  other  software.  The  executable  lines  of  code  metric  shall  treat  instructions  exe¬ 
cuting  on  the  same  clock  cycle  in  the  same  processor  as  a  single  line  of  code  and,  in  addition,  will  generate 
the  histogram  (MICRO_HIST)  of  the  number  of  instmctions  which  are  executing  on  each  clock  cycle. 

4.3.4.9  VHDL.  The  same  concept  of  a  uniform  style  that  is  so  important  to  common  programming 
languages  is  also  important  to  VHDL.  All  of  the  software  metrics  previously  described  in  this  section  that 
are  normally  applied  in  the  course  of  evaluation,  with  the  exception  of  the  Halstead  metric,  shall  also  be 
applied  to  the  VHDL  language  as  shall  the  metric  associated  with  the  use  of  a  configuration  management 
process.  Although  this  language  is  less  mature,  the  techniques  developed  and  tested  for  other  languages,  can 
be  brought  to  bear.  The  VHDL  code  which  had  been  automatically  generated,  as  contrasted  with  hand  writ¬ 
ten  code,  is  specifically  excluded  from  this  requirement.  As  we  have  observed  that  the  simulation  time  using 
VHDL  models  may  be  large,  the  wall  clock  time  shall  be  measured  whenever  it  exceeds  one  minute.  This 
shall  be  presented  in  a  histogram  fashion  (VHDL_HIST).  The  execution  time  relative  to  real  time  shall  be 
measured  for  representative  VHDL  simulations  (VHDL_SIM_'nME). 

4.3.5  Documentation 

A  common  measure  of  comprehension  is  the  Resch  readability  metric  [5].  This  is  normally  evaluated 
according  to  the  table  below  which  is  appropriate  for  maintenance  manuals,  training  manuals,  or  user 
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guides.  This  metric  (FLESCH)  is  incorporated  into  the  current  version  of  WordPerfect  and  is  shown  in  Table 
25.  In  addition,  the  scale  of  the  Flesch  metric  needs  to  be  adjusted  according  to  the  intended  audience.  As 
shown  in  Table  26,  a  level  that  is  quite  appropriate  for  one  class  may  be  barely  comprehensible  to  a  different 
class.  This  metric,  or  the  alternative  FOG  metric  (see  below),  shall  be  applied  to  any  training  or  maintenance 
manuals  associated  with  the  delivered  hardware.  The  metric  is  not  intended  for  application  to  milestone  re¬ 
ports  and  other  forms  of  interim  documentation. 


TABLE  25 
Flesch  Metric 


Score 

Reading  Difficulty 

Grade  Level 

90-100 

Very  Easy 

4th  grade 

80-90 

Easy 

5th  grade 

70-80 

Fairly  Easy 

6th  grade 

60-70 

Standard 

7th-8th  grade 

50-60 

Fairly  Difficult 

Some  High  School 

30-50 

Difficult 

High  School  to  College 

0-30 

Very  Difficult 

College  and  up 
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TABLE  26 

Association  of  Flesch  Metric  and  Audience  Level 


Score 

Maintenance  Manual 

Technical  Manual 

90-100 

Appropriate 

Insulting 

80-90 

Appropriate 

Risk  losing  reader’s  interest 

30-50 

Risk  of  losing  reader’s  interest 

Appropriate 

0-30 

Incomprehensible 

Appropriate 

An  alternative  readability  metric  is  the  Gunning  Fog  Index.  This  measures  the  length  of  sentences  and 
the  percentage  of  “hard”  words,  where  a  word  falls  into  this  category  if  it  has  more  than  two  syllables.  The 
metric  (FOG)  is: 


FI  =  0.4  X 


WRD 

SEN 


HRD\ 

WRDJ 


xlOO 


The  interpretation  of  FI  is  shown  in  Table  27. 


(5) 


TABLE  27 

Fog  Index  Interpretation 


Index 

interpretation 

Fl<5 

Fairly  Easy 

5<FI<8 

Standard 

8<FI<11 

Fairly  Difficult 

11<FI<17 

Difficult 

17<FI 

Very  Difficult 

90 


5.  DELIVERABLES 


This  section  provides  additional  information  on  the  deliverables  required  for  Benchmark-2. 

5.1  PROCESSOR 

5.1.1  Prototype  Designs 

In  response  to  this  BTD,  each  RASSP  Developer  shall  estimate  costs  for  three  versions  of  the  proces¬ 
sor  design  selected  in  Benchmark-1  for  virtual  prototyping.  One  version  would  provide  up  to  three  polar¬ 
izations  of  output  image  data,  the  second  version  would  provide  only  one  output  polarization,  and  the  third 
version  would  provide  as  much  functionality  as  possible  for  a  total  cost  of  less  than  $500K  for  the  bench¬ 
mark.  If  the  single  or  triple  polarization  options  cost  less  than  $500K,  the  option  for  “maximum  functional¬ 
ity  for  less  than  $500K”  may  be  dropped.  In  all  cases,  the  polarization  of  the  output  data  must  be  selectable 
from  among  the  four  polarizations  of  input  data  and  the  design  hardware  must  be  fabricated  within  the  six- 
month  benchmark  cycle.  All  designs  must  adhere  to  the  technical  requirements  discussed  in  Section  2  and 
must  be  producible  in  unit  quantities  within  the  time  and  effort  constraints  established  for  Benchmark-2. 
Only  one  of  the  designs  will  be  selected  for  prototype  development. 

Accompanying  the  prototype  processor  shall  be  the  VHDL  from  which  the  prototype  was  produced. 

5.1.2  Accuracy  Requirements 

The  RASSP  Developer  must  demonstrate  a  prototype  processor  that  meets  the  accuracy  requirements 
described  in  Section  2.1.1.  During  the  course  of  Benchmark- 1 ,  the  Developer  may  have  proposed  a  modified 
accuracy  requirement.  If  this  modified  requirement  is  approved  for  use  in  Benchmark-2,  the  Developer  may 
demonstrate  a  prototype  processor  that  meets  the  modified  accuracy  requirements  rather  than  the  require¬ 
ments  described  in  Section  2.1.1.  The  RASSP  Developer  must  fully  describe  the  modified  requirement  and 
demonstrate  that  it  adequately  characterizes  the  performance  of  the  processor. 

5.1.3  Product  Acceptance 

Acceptance  testing  of  the  RASSP  processor  prototype  shall  be  performed  at  the  Developer’s  site  us¬ 
ing  the  data  source/sink  furnished  by  the  Benchmarker. 

All  prototype  processors  and  associated  software  developed  in  the  course  of  Benchmark-2,  exclusive 
of  compilers  and  simulators,  shall  be  delivered  to  the  Government  after  successful  acceptance  testing.  Li¬ 
censes  for  any  commercial  software  libraries,  operating  systems,  etc.,  exclusive  of  compilers  and  simula¬ 
tors,  shall  also  be  delivered  to  the  Government  or  their  designee.  In  addition  to  delivering  the  processor 
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hardware,  the  Developers  must  supply  a  spare  for  every  unique  board  in  the  system.  A  spare  power  supply 
must  also  be  provided. 

The  Government  and  the  Benchmarker  shall  designate  witnesses  for  the  acceptance  testing,  and  the 
Government  shall  decide  whether  to  accept  delivery  of  benchmark  prototype  test  articles  based  on  the  out¬ 
come  of  the  acceptance  testing.  The  Government  may  elect  to  transfer  the  benchmark  test  articles  to  the 
Benchmarker  for  the  purpose  of  measuring  test  article  compliance  with  all  requirements  included  in  the 
BTD,  and  assessing  test  article  design  margins. 

52  METRICS 

In  addition  to  prototype  hardware  and  associated  software,  the  Developer  shall  deliver  the  metrics  list¬ 
ed  in  Section  5.2.1  and  described  in  Section  4.  Other  metric  deliverables  are  discussed  in  Section  5.2.2 
through  Section  5.2.5. 

The  metrics  enumerated  in  Section  5.2.1  through  Section  5.2.5  must  be  applied  in  a  framework  which 
considers  the  mode  of  project  development  as  well  as  phase  of  the  project  (see  Section  4).  Each  developer 
must,  therefore,  supply  development  mode  and  project  phase  data  with  each  delivered  metric. 

All  metric  deliverables  are  due  at  milestone  times  discussed  in  Section  5.3. 


5.2.1  Metric  Deliverable  Lists  (MDLs) 

5.2.1.1  PRICE-S  MDL. 


TABLE  28 

PRICE-S  Metric  Deliverable  List 


DESCRIPTION 


SECTION 


METRICS 


Development  CSCI 


Section  4.2. 1.1.1 


PLTFM 

CPLXM 

INTEGI 

UTIL 

SCON 

SDR 

SSR 

SRR 

PDR 

CDR 

TRR 

FCA 

PCA 

FOR 

OTE 
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TABLE  28  (Continued) 
PRICE'S  Metric  Deiiverabie  List 


DESCRIPTION 

SECTION 

METRICS 

Purchased  CSCI 

Section  4.2.1 .1.2 

LANG 

SLOC 

FRAC 

APPL 

INTEGE 

PCOST 

UNITS 

RATE 

RATE  TIME  UNIT 
PLTFM 

Furnished  CSCI 

Section  4.2. 1.1. 3 

LANG 

SLOC 

COST 

FRAC 

APPL 

INTEGE 

PLTFM 

Calibration  CSCI 

Section  4.2. 1.1. 4 

PLTFM 

CMPLXM 

INTEGI 

INTEGE 

UTIL 

COST 

SCON 

SDR  or  SSR 

SRR 

PDR 

CDR 

TRR 

FCA 

FOR 

OTE 
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TABLE  28  (Continued) 
PRICE'S  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Development  CSC 

Section  4.2. 1.1. 5 

INTEGI 

INTEGE 

UTIL 

SSR 

PDR 

CDR 

TRR 

FCA 

Purchased  CSC 

Section  4.2.1. 1.6 

LANG 

SLOC 

FRAC 

APPL 

INTEGE 

PCOST 

UNITS 

RATE 

RATE  TIME  UNIT 

Furnished  CSC 

Section  4.2.1 .1.7 

LANG 

SLOC 

FRAC 

APPL 

INTEGE 

Language 

i 

Section  4.2. 1.1. 8 

i 

LANG 

SLOC 

FRAC 

CPLX1 

CPLX2 

PROFAC 

APPL 

NEWD 

NEWC 
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TABLE  28  (Continued) 
PRICE'S  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Commercial  sizing 

Section  4.2.1. 2.1 

INTEGRATION 
DESIGN  REVIEW 
CODE  W/T 

T/D  APPROACH 
MODULE  TESTING 
OUTP 

OUTS 

OUTD 

INPF 

OUTF 

SCRF 

COPT 

INPFV 

COMVA 

LANG 

TARSIZ 

SICAL 

REQG 

FBULK 

Military  sizing 

1 

i 

! 

Section  4.2. 1.2.2 

MIL/COM 

1  INTEGRATION 
DESIGN  REVIEW 
CODE  W/T 

T/D  APPROACH 
MODULE  TESTING 
OUTP 

ALPD 

GRAFD 

INPST 

OUTST 

CSTATE 

INPMF 

INPDK 

INPAN 

COMTA 

FBULK 

REQG 

SICAL 

TARSIZ 

LANG 
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TABLE  28  (Continued) 
PRICE-S  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Life  cycle 

Section  4.2.1 .3 

PLTFM 

UTiL 

SSR 

SCHFAC 

DEVCST 

DEVU 

RATE  TIME  UNIT 
RATE 

5.2.1^  PRICE-M  MDL. 


TABLE  29 

PRICE-M  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Module  general  A 

Section  4.2.2.1 .1 

QTY 

PROTOS 

LENGTH, 

WIDTH 

LAYERS 

PLTFM 

NAME 

Module  general  B 

Section  4.2.2. 1.2 

MBINDX 

BTYPE 

BSIDE 

BOOST 

PTYPE 

PPINS 

PCOST 

ATCOST 

PRICE-H  interface 

Section  4.2.2.1. 3 

QTYNHA 

INTEGE 

HSINT 

WEIGHT 

VOLUME 

BWT 

PWT 
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TABLE  29  (Continued) 
PRICE-M  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Module  development 

Section  4.2.2. 1.4 

ECMPLX 

NEWDES 

DESRPT 

Mod.  development  schedule 

Section  4.2.2.1.5 

□START 

DFPRO 

DLPRO 

DBINDX 

Mod.  production  schedule 

Section  4.2.2.1 .6 

PSTART 

PFAD 

PEND 

MAUTO 

MMAT 

Mod.  supplemental  info. 

i 

Section  4.2.2. 1.7 

YRECON 

YRBASE 

YRTECH 

AUCOST 

ETCOST 

PRCOST 

Mod.  component  data 

i 

j 

Section  4.2.2. 1.8 

CNUM 

CNAME 

CELM 

CTYPE 

CPKG 

CPINS 

CWT 

CCOST 

Microcircuit  general 

Section  4.2.2.2.1 

QTY 

PROTOS 
LENGTH, WIDTH 
PINS 

GATES 

XSTRS 

CNAME 
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TABLE  29  (Continued) 
PRICE-M  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Micro,  development 

Section  4.2.2.2.2 

DPLTFM 

SPLTFM 

□INDEX 

CMPLX 

NEWCEL 

DESRPT 

CADFAC 

TERAT 

Micro,  production  A 

Section  4.2.2.2.3 

PROFAC 

MINDEX 

PKGFAC 

SUBFAC 

LOTQTY 

WSIZE 

FSIZE 

Micro,  production  B 

Section  4.2.2.2.4 

CPYLD 

ASMYLD 

OVLYLD 

MSKLVL 

DEFDEN 

MAUTO 

MMAT 

Micro,  dev.  schedule 

Section  4.2.2.2.5 

DSTRT 

PTSRT 

PTEND 

TSTEND 

DEND 

Micro,  prod,  schedule 

Section  4.2.2.2.6 

PSTRT 

PPEND 

PEND 

Micro,  supp.  info. 

Section  4.2.2.2.7 

YRECON 

AUCOST 

Database 

Section  4.2.2.3 

PLTFM 

YRBASE 

5.2.1.3  PRICE-H  MDL. 


TABLE  30 

PRICE-H  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Project  magnitude 

Section  4.2.3.1 

QTY 

PROTOS 

PROSUP 

WT 

WS 

WECF 

WSCF 

VOL 

USEVOL 

Customer  requirements 

Section  4.2.3.2 

PLTFM 

MREL 

EREL 

Design  complexity 

Section  4.2. 3.3 

HYBRID 

IC 

LSI 

VLSI 

MCONST 

MEXP 

MCPLXS 

MCPLXE 

AUCOST 

PTCOST 

PRCOST 

DTCOST 

Engineering  complexity 

Section  4.2.3.4 

ECMPLX 

SE 

New/used  design 

Section  4.2.3.5 

NEWST 

DESRPS 

NEWEL 

DESRPE 
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TABLE  30  (Continued) 
PRICE-H  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Schedule  impact 

Section  4.2.3.6 

PSF 

DSTART 

DEND 

DFPRO 

DLPRO 

PSTART 

PFAD 

PEND 

TCALD 

TCALP 

NSHIFT 

NFACS 

Technology  growth 

Section  4.2.3.7 

YRTECH 

ZTECH 

TECDEL 

H/W  and  SA/V  integration 

Section  4.2.3.8 

HSINT 

LANG 

SLOC 

FRAC 

APPL 

CPLXM 

System  integration 

Section  4.2.3.9 

QTYNHA 

INTEGE 

INTEGS 

EPLANS 

SPLANS 
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TABLE  30  (Continued) 
PRiCE-H  Metric  Deliverable  List 
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TABLE  30  (Continued) 
PRiCE-H  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

Other  costs 

Section  4.2.3.11 

PTLGTS 

ETLG1 

ETLG2 

STLG1 

STLG2 

YRBASE 

YRECON 

DLEVE 

DLEVS 

DMULT 

PMULT 

SYSTEM 

ECNE 

ECNS 
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5.2.1.4  PRICE-HL  MDL. 


TABLE  31 

PRICE-HL  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Life  cycle 

Section  4.2.4 

MTBF 

TF 

TMO 

EE 

FN 

CEND 

CPE 

CUR 

CMR 

TRE 

P 

PP 

FNSP 

CPPE 

CFIM 

CFIP 

FTSQF 

FTSQP 

TC 

ccou 

FTSQC 

DSTART 

DEND 

PSTART 

PEND 

CUP 

CMP 

CPP 

YRECON 

YAT 
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5.2.1.5  SEER-SEM  MDL. 


TABLE  32 


SEER-SEM  Metric  Deliverable  List 


DESCRIPTION 


Size  of  new  code 


Size  of  old  code  (reuse) 


Complexity 


Personnel  capabilities 


Development  support 


Product  development 


Product  reusability 


SECTION 


Section  4.2.5. 1.1 


Size  of  old  code  (non-reuse)  Section  4.2.5.1 .2 


Section  4.2.5.1 .3 


Section  4.2.5.2 


Section  4.2.5.3 


Section  4.2.5. 4 


Section  4.2.5.5 


Section  4.2.5.6 


METRICS 


NEWLOC 


OLDLOC 

DELLOC 

CHGLOC 

PCREDESIGN 

PCREIMPL 

PCRETEST 


OLDLOC 

DELLOC 

PCREDESIGN 

PCREIMPL 

PCRETEST 

COMPLEX 


ANALCAP 

ANALEXP 

PROGCAP 

PROGLANG 

DEVELEXP 

TARGETEXP 

METHODEXP 


MODDEVEL 

AUTOTOOL 

TURN- 

AROUNDTM 

TERMINALTM 

MULTSITE 

RESDEDIC 

RESLOC 

HOSTVOL 

METHODVOL 


REQVOL 

SPECLVL 

TESTLVL 

QALVL 

REHOST 


REUSELVL 

SWREUSE 
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TABLE  32  (Continued) 
SEER-SEM  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Development  environment 

Section  4.2.5.7 

LANGCMPLX 

HOSTCMPLX 

APPCMPLX 

PRACCMPLX 

Target  environment 

Section  4.2.5.8 

DISPLAY 

MEMORY 

TIME 

COPLEX 

VOLATILE 

SECURE 

Schedule 

Section  4.2.5.9 

SCHEDULE 

Staffing 

Section  4.2.5.10 

MAXPERYR 

MAXTOT 

MAXEFFRT 

Probability 

Section  4.2.5.11 

PROS 

Software  requirements 

Section  4.2.5.12 

REQCON 

REQFORM 

REQBASE 

S/W  to  S/W  integration 

Section  4.2.5.13 

CONCURI 

ORGS 

EXTINTERF 

S/W  to  H/W  integration 

Section  4.2.5.14 

HWINTLVL 

UNIHW 

Software  maintenance 

Section  4.2.5.15 

YRMAIN 

SITES 

MAINGROW 

PERSDIFF 

ENVDIFF 

ACR 

MAINTOT 

Add-ons 

Section  4.2.5.16 

EXTQA 

PO 

IVV 
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TABLE  32  (Continued) 
SEER-SEM  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Avg.  personnel  costs 

Section  4.2.5.17 

SWMNG 

SWSR 

SWR 

SWD 

SWP 

SWQA 

SWCM 

SWDP 

5.2.1.6  SEER-SSM  MDL. 

TABLE  33 

SEER-SSM  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Pairwise 

Section  4.2.6. 1 

PAIRWS 

PERT  sizing 

Section  4.2.6. 2 

TOTLOC 

LIKESZ 

HIGHSZ 

Sorting 

Section  4.2.6. 3 

SORT 

Ranking 

Section  4.2.6.4 

RANK 
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52AJ  SEER-IC  MDL. 


TABLE  34 

SEER-IC  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Product 

Section  4.2.7.1 

CHIPA 

MCMA 

NOMCM 

FSZ 

TPERCHIP 

GPERCHIP 

lOPERCHIP 

PTYPE 

WSZ 

Mission 

Section  4.2.7.2 

CLASS 

OPENV 

Program 

Section  4.2.7.3 

NEWD 

ITER 

CERT 

Development  environment 

Section  4.2.7.4 

DEVCAP 

DEVTOOL 

REQVOL 

Product  environment 

Section  4.2.7.5 

PROEXP 

PROTOOL 

Program  schedule 

Section  4.2.7.6 

STARTDEV 

PROQTY 

STARTPRO 

YLD 

Production 

Section  4.2.7.7 

PRIPRO 

TOTPRO 

PCPURCH 

PURCHCST 

Probability 

Section  4.2.7.8 

PROS 

Economic  factors 

Section  4.2.7.9 

DEVFEE 

PROFEE 
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TABLE  34  (Continued) 


SEER-IC  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Project  parameters 

Section  4.2.7.10 

QTY 

STARTMO 

EXCHG 

BASEYR 

CSTESC 

DTBS 

5.2.1.8  SEER-H  MDL. 

TABLE  35 


SEER-H  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Electronic  product 

Section  4.2.8.1.1 

TOTPCB 

CKTCOMP 

COMPCB 

ICPCB 

lOPCB 

CLOCK 

DENSE 

ICTECH 

Electronic  mission 

Section  4.2.8. 1.2 

OPENV 

CLASS 

FLTDET 

FLTISO 

Electronic  program 

Section  4.2.8. 1.3 

NEWD 

DESREP 

CERT 

HDINTLVL 

Mechanical  product 

Section  4.2.8.2.1 

WEIGHT 

VOLUME 

MATERIAL 

FORMCMPLX 

FITCMPLX 

CONSTR 
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TABLE  35  (Continued) 
SEER-H  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Mechanical  mission 

Section  4.2.8.2.2 

OPENV 

CLASS 

SRVLIFE 

PRESS 

Mechanical  program 

Section  4.2.8.2.3 

NEWD 

DESREP 

CERT 

HDINTLVL 

Development  environment 

Section  4.2.8.3.1 

DEVCAP 

DELTOOL 

REQVOL 

Production  environment 

Section  4.2.8.3.2 

PROEXP 

PROTOOL 

Program  schedule 

i 

Section  4.2.8.3.3 

DEVSCHED 

DEVSTART 

PROTOQTY 

PROSTART 

LEARN 

PRIPRO 

PROQTY 

Purchased  items 

Section  4.2.8.3.4 

PCPURCH 

PURCHCST 

UNITCST 

PROS 

Economic  factors 

Section  4.2.8.3.5 

ENGRT 

MFGRT 

MATCST 
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5.2.1.9  SEER-HLC  MDL. 

TABLE  36 


SEER-HLC  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Project  parameters 

Section  4.2.9.1 

NAME 

OSSTART 

OSDUR 

INFLATE 

FYSTART 

COSTBY 

ORGHRRATE 

INTHRRATE 

DEPHRRATE 

Site  parameters 

Section  4.2.9.2 

SITEID 

SHIFTS 

SYSQTY 

OPSTART 

OPEND 

Support  parameters 

Section  4.2.9.3 

SUPSUITE 

CSTSUITE 

AVAIL 

Prime  mission  equipment 

Section  4.2. 9. 4 

WBS 

NAME 

QTY 

WEIGHT 

OPHRS 

OPHRSMAT 

REPLACE 

SPARES 

CCR 

ARC 

MTTF 

CONDEMN 

RETESTOK 

PME  organization 

Section  4.2.9.4.1 

MTTR 

REPAIRRT 

SUPPEQ 

HRRT 

AVAIL 

PSECOST 
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TABLE  36  (Continued) 
SEER-HLC  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

PME  intermediate 

Section  4.2.9.4.2 

MTTR 

TURNAROUND 

SUPPEQ 

HRRT 

AVAIL 

PSECOST 

NRTSRT 

PME  depot 

Section  4.2.9.4.3 

MTTR 

TURNAROUND 

SUPPEQ 

HRRT 

AVAIL 

PSECOST 

5.2.1.10  Design  Process  MDL. 

TABLE  37 


Design  Process  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Design  process 

Section  4.3.1 

TOOL_USAGE 

TOOL_VALUE 

TOOL_OPEN 

TOOL_DACCESS 

TOOL_GUI 

TOOLJNTFCE 

TOOL_PROJDAT 

TOOL_PROJMGT 

TOOL_LIBMGT 
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TABLE  37  (Continued) 
Design  Process  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Reuse 

Section  4.3.1 .2.1 

REUSE_ENT  T 
REUSE_ENT  C 
REUSE_ORIG_T 
REUSE_ORIG  C 

REUSE  EVAL  T 
REUSE_EVAL  C 
REUSE_T 

REUSE_C 

REUSE_TRATIO 

REUSE_CRAT10 

Software  reuse 

Section  4.3.1. 2.1 

S_REUSE_ORIG_T 
S_REUSE_ORIG_C 
S.REUSE  EVAL  T 
S_REUSE_EVAL  C 
S_REUSE_T 
S_REUSE  C 
S.REUSE  Tl 
S_REUSE  Cl 
S_REUSE_LOC 
S_REUSE_DEFECT 

Defects 

Section  4.3.1 .3 

DEFECT_FIND 

DEFECT  SRC 
DEFECT_UNDO_T 
DEFECT  UNDO  C 
DEFECT  LOST  T 
DEFECT_LOST_C 
DEFECT_TTM 

Requirements  traceability 

Section  4.3.1 .4 

REQ_TRAC 
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5.2.1.11  Application  Complexity  MDL. 


TABLE  38 

Application  Complexity  Metric  Deliverable  List 
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TABLE  38  (Continued) 
Application  Complexity  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

llity  requirements 

Section  4.3.2.3 

FLTCOV 

FLTLAT 

FLTISO 

MAXFLTRT 

MAXFLTREC 

SKILL 

DOC 

5.2.1.12  Hardware  Product  MDL. 


TABLE  39 

Hardware  Product  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Performance 

Section  4.3.3.1 

EXRATE 

PROPS 

MPROPS 

lOPEAK 

lOSUS 

DYNAMIC 

PKPOW 

AVGPOW 

SIZE 

WEIGHT 

COST 

TEST 

RELY 

AVAIL 

ENVIRONMENT 

TABLE  39  (Continued) 
Hardware  Product  Metric  Deliverable  List 


5^.  1.13  Software  Product  MDL. 

TABLE  40 


Software  Product  Metric  Deliverable  List 


DESCRIPTION 

SECTION 

METRICS 

Lines  of  code 

Section  4.3.4.1  for 
each  category  of 
Table  15 

LOC_COCO 

LOC_EXEC 

LOC.AVG 

LOC_MED 

LOC_MAX 

Software  style 

Section  4.3.4.2 

STYLE_EXIST 

STYLE 

Software  revision  control 

Section  4.3.4.3 

CNFG_MGT 
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TABLE  40  (Continued) 
Software  Product  Metric  Deliverable  List 


DESCRIPTION 


Software  code  metrics 


SECTION 


Section  4.3.4.4 


Code  defects 


Section  4.3.4.5 


Software  cohesion 


Section  4.3.4.6 


Software  interfaces 


Section  4.3.4.7 


METRICS 


HAL_N_OPTOR 

HAL_N_OPAND 

HAL_N_OCC_R 

HAL_N_OCC_D 

HAL_VOCAB 

HAL_OB_LEN 

HAL_ES_LEN 

HAL_VOL 

HAL_DIFF 

MCCABE_CCN 

FENTON 

V_CONCURRENCY 

V_SIGNALS 

V_ACCESS 

V_ABSLEV 

V_STRUCTURES 

D_SPEC 

D.LOGIC 

D_UI 

D_EC 

D_HWI 

D_SWI 

D_DH 

D_STD 

DEFECT_TST 

DEFECT_RES 


SCOHE_PD 

SCOHE_AVG 

SCOHE_MED 

SCOHE_MAX 


SINTERF_PD 
SINTERF_AVG 
SINTERF_MED 
SINTERF  MAX 


VHDL  simulation  time 

Section  4.3.4.9 

VHDL_HIST 

vhdl_sim_time 
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5.2.2  Tool  Elements 


The  maturity  and  the  integration  of  the  tools  in  use  at  each  stage  of  the  RASSP  process  must  be  mea¬ 
sured  and  reported  by  the  Developer  (see  Table  9).  Mature  tools  used  at  the  very  late  stages  of  the  process, 
such  as  compilers,  are  known  to  be  very  stable.  The  same  statement  cannot  be  made  about  the  new  tools 
now  becoming  available  to  assist  in  the  early  stages  of  the  design  process.  The  amount  of  time  spent  on  the 
telephone  with  each  tool  vendor  attempting  to  resolve  discrepancies  in  performance  (a  defect)  relative  to 
the  documentation  or  advertised  performance  is  a  metric  that  must  be  accurately  reported.  Defects  must  be 
reported  consistent  with  Section  4.3.1 .3  and  Table  12  at  each  Milestone. 

5.2.3  Reuse  Libraries 

The  use  of  libraries  and  the  amount  of  design  time  that  can  be  saved  through  their  use  is  an  important 
part  of  the  RASSP  process.  This  is  applicable  to  the  hardware,  software,  and  even  subsystem  elements  of 
each  benchmark.  The  concept  of  reuse  is  applicable  at  all  levels.  To  this  end,  the  amount  of  time  spent  in 
exploring  the  reuse  libraries  for  applicability,  the  time  saved  by  not  implementing  an  original  design,  and 
the  time  spent  in  adapting  an  element  of  the  reuse  library  to  the  current  benchmark  must  all  be  measured  or 
estimated  as  appropriate  by  the  Developer.  The  amount  of  time  spent  re-evaluating  the  potential  elements 
of  the  reuse  library  because  the  documentation  is  inadequate  for  the  decision  making  process  is  a  metric  that 
must  be  accurately  reported.  Other  metrics  to  be  reported  by  the  Developer  are  described  in  Section 
4.3.1.2.1  (Table  10  and  Table  11). 

5.2.4  Documentation 

Documentation  should  be  readable  and  up  to  date.  Documentation  generated  as  part  of  the  benchmark 
must  be  in  a  computer-readable  format  in  ASCII  or  word  processor  format  which  can  be  imported  into 
Word  6.0  or  WordPerfect  6.0.  A  PostScript  file  is  not  considered  to  be  computer-readable.  The  Flesch  read¬ 
ability  metric,  or  equivalent,  will  be  applied  by  the  Developers  to  all,  or  at  least  some  portion,  of  any  training 
and  maintenance  documentation.  Online  documentation  must  be  evaluated  for  its  pertinence,  accuracy,  and 
level  of  detail. 


5.2.5  Software  Metrics 

During  the  course  of  each  benchmark,  software  baselines  shall  be  created  by  the  Developer  as  a  de¬ 
liverable  item  and  are  due  at  the  milestones  discussed  m  Section  5.3.  For  the  purposes  of  this  benchmark, 
software  specifically  includes  VHDL  code.  A  baseline  is  not  intended  to  be  comprehensive  or  a  final  version 
but  is  intended  to  represent  a  working  package  for  some  subset  of  the  overall  task.  As  a  result  of  experience 
gained  from  Benchmark- 1,  forms  for  tracking  software  development  through  all  development  phases  will 
be  used  for  Benchmark-2.  It  is  recommended  that  the  Developer  conform  to  the  tracking  and  reporting  spec¬ 
ification  of  [15]  for  each  type  of  software  developed  (i.e.,  Ada  and  VHDL).  At  a  minimum,  however,  the 
Developer  shall  create  and  deliver  forms  for  each  type  of  developed  software  and  update  the  entries  with 
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each  release  of  the  software  baseline;  a  sample  form  is  shown  in  Table  41.  Sufficient  detail  shall  be  made 
available  for  each  entry  to  allow  an  understanding  of  how  each  entry  was  derived.  The  Developer  shall  cre¬ 
ate  and  deliver  similar  but  less  detailed  forms  to  track  the  lines-of-code  and  defects  of  each  software  type 
on  a  weekly  basis  (Section  4.3.4). 

The  Developer  shall  apply  the  set  of  software  metrics  described  in  the  section  on  Software  Products 
(Section  4.3.4)  to  each  version  of  the  baseline  software.  The  benchmark  evaluation  process  will  apply  a  set 
of  metrics  to  all  baseline  software  delivered  with  the  benchmark  [4]  as  appropriate.  During  the  course  of  the 
benchmark,  baseline  software  which  has  been  identified  as  lacking  in  specified  features  intended  for  a  later 
version  will  not  be  considered  to  contain  a  defect  for  these  omissions. 

Whatever  style  guides  a  Developer  imposes  for  software  development  at  the  beginning  of  each  bench¬ 
mark  are  considered  deliverable  items.  It  is  the  intent  to  track  these  over  the  course  of  the  RASSP  program. 
A  description  of  the  configuration  management  tools  that  are  in  place  at  the  beginning  of  a  benchmark  is  a 
deliverable  item.  During  the  course  of  the  benchmark,  all  occurrences  of  bypassing  the  configuration  man¬ 
agement  protocols  must  be  reported  by  e-mail,  or  a  suitable  equivalent,  to  a  central  repository.  The  contents 
of  the  repository  become  a  deliverable. 

The  developer  shall  indicate  the  perceived  level  of  conformance  to  the  SEI  Capability  Maturity  Model 
at  the  beginning  of  each  benchmark.  Note  that  this  is  not  intended  to  be  a  formal  CMM  review.  This  level 
is  to  be  based  exclusively  on  the  software  methodology  in  place  for  the  RASSP  program  and  is  not  to  be 
based  on  methodology  available  in  other  parts  of  the  Developer’s  company,  no  matter  how  advanced  it  may 
be. 


The  contents  of  code  inspections  and  their  results  form  part  of  the  deliverables.  This  includes,  of 
course,  structure  charts  and  flow  diagrams. 

5.3  MILESTONE  REPORTS 

Up  to  date  software,  prototype  design,  schematics,  hardware,  and  metric  deliverables  shall  be  provid¬ 
ed  at  each  milestone  reached  during  each  benchmark  cycle.  The  milestones  are  to  be  defined  by  the  Devel¬ 
oper  and  clearly  described  in  the  response  to  this  Benchmark  Technical  Description.  Four  milestone  reviews 
are  required.  The  first  review  should  correspond  to  the  time  at  which  the  system  design  is  complete  and 
ready  for  fabrication  or  procurement,  essentially  a  CDR.  The  second  milestone  review  should  correspond 
to  the  time  at  which  the  hardware  is  available  for  integration  with  the  software.  The  third  and  fourth  review 
are  left  to  the  discretion  of  the  Developer.  One  basis  for  choosing  the  third  and  fourth  milestones  is  to  key 
the  third  to  successful  integration  of  the  hardware  and  software,  and  the  fourth  to  expiration  of  the  six  month 
benchmark  time  period. 

However,  apreferred  approach  is  to  key  the  third  and  fourth  milestones  to  the  Developer’s  design  pro¬ 
cess.  As  an  example,  assuming  a  spiral  development  model  for  the  RASSP  process  [11],  the  third  and  fourth 
milestones  might  be  keyed  to  completion  of  a  loop  around  the  spiral.  Figure  10  shows  a  nominal  spiral  de¬ 
velopment  model  for  Benchmark-2,  with  three  spiral  cycles  occurring  within  a  six-month  benchmark  cycle. 
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TABLE  41 

Tracking  Code  Development 


Require" 

ments 

Analysis 

System 

Design 

Detailed 

Design 

Code  Pro¬ 
duction 

Unit  Test 

Integraion 

Test 

System 

Test 

Original 

LOCEst. 

Revised 
LOC  Est. 

LOC 

Produced 

LOC 

Released 

Estimated 

Effortf 

Revised 

Effort! 

Actual 

Effort! 

Est# 

Defects 

Act# 

Defects 

^  In  units  of  person-month 


Each  spiral  cycle  encompasses  four  phases  of  development.  The  processes  starts  with  a  plaiming 
phase.  However,  for  Benchmark-2  it  is  assumed  that  initial  design  planning  occurred  with  Benchraark-1  and 
is  represented  by  the  dotted  line  in  Figure  10.  Thus,  Benchmark-2  formally  begins  with  a  requirements  re¬ 
view.  The  phase- 1  consists  of  developing  preliminary  designs.  These  designs  are  evaluated  within  the 
phase-2  after  which  a  single  best  design  is  identified.  Phase-3  continues  design  development  while  design 
deficiencies,  if  any,  are  identified.  Phase-4  uses  design  information  gather  during  the  three  preceding  phases 
to  prepare  for  the  next  spiral  cycle.  Reporting,  software,  prototype  design,  and  metric  deliverables  shall  be 
due  at  the  completion  of  each  phase  of  each  spiral  cycle.  Figure  1 1  shows  a  Gantt  chart  for  the  spiral  model 
of  Figure  10. 
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PRELIMINARY 

REVIEW 


READINESS 

REVIEW 


Figure  10.  Spiral  development  model  for  Benchmark-2. 
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Figure  IL  Gantt  chart  for  Benchmark-2  milestone  reports. 


At  the  start  of  Benchmark-2,  each  Developer  shall  provide  details  on  the  specific  development  model 
to  be  used  throughout  the  benchmark  cycle,  including  descriptions  of  the  development  phases.  At  the  start 
of  Benchraark-2,  each  developer  shall  generate  a  detailed  schedule  of  milestones  and  deliverables  (i.e.,  re¬ 
ports,  metrics)  for  the  entire  benchmark  cycle.  At  each  milestone,  each  Developer  will  provide  actual  sched¬ 
ules  of  activity  to  be  compared  with  those  generated  at  the  start  of  Benchmark-2. 

Informal  reports  are  due  at  each  milestone  that  correspond  to  the  deliverables  required  for  each  mile¬ 
stone.  In  addition,  these  reports  shall  review  progress  and  problems  encountered  since  the  last  milestone  re¬ 
view.  Formal  milestone  reports  shall  also  incorporate  comprehensive  management  data  including  actual  and 
projected  costs  and  schedule  for  the  benchmark.  Formal  milestone  reports  shall  include  a  comprehensive 
representation  of  the  design  database  at  the  time  the  milestone  was  reached.  Formal  milestone  reports  will 
not  be  required  more  frequently  than  once  per  month  over  the  duration  of  Benchmark-2,  except  in  the  event 
that  the  benchmark  execution  is  completed  in  substantially  less  time  than  originally  estimated  by  the  Devel¬ 
oper.  All  milestone  reports  shall  be  sufficiently  comprehensive  so  that,  when  taken  as  a  whole,  they  provide 
a  detailed  description  of  the  progress  and  problems  encountered  in  completing  execution  of  the  benchmark. 

5.4  ELECTRONIC  REPORTING 

Unless  otherwise  agreed  upon  in  writing,  the  Developer  shall  supply  all  non-hardware  deliverables 
and  reports  in  the  following  electronic  formats.  Where  multiple  formats  are  noted,  the  Developer  can  select 
the  format  most  appropriate  to  the  data  item.  Style  and  format  files  must  also  be  supplied  whenever  either 
is  required  to  view  or  print  a  data  item. 

•  Schedules  -  Microsoft  Project  or  a  compatible  format 

•  Reports/Documentation  -  WordPerfect,  Microsoft  Word,  or  Framemaker 

•  Spreadsheet  -  Microsoft  Excel  or  a  compatible  format 

•  Project  Data  -  Both  native  tool  format  and  project-wide  database  format 

•  HOL/HDL  Source  code  -  ASCII  machine-readable  format 

The  digital  data  may  be  provided  via  an  Exabyte  model  8200  or  8500  uncompressed  tar  format  8mm 
tape,  or  via  an  FTP  site  accessible  over  the  Internet.  Wherever  requested  in  the  BTD  for  a  given  benchmark, 
the  deliverables  shall  also  be  supplied  in  printed  form.  Password  protection  may  be  used  for  security  at  the 
Developers’  option. 

5.5  BENCHMARK  PERSONNEL  REPORTING 

During  the  execution  of  the  benchmark,  each  of  the  individuals  may  be  required  to  participate  in  in¬ 
formal,  but  regularly  scheduled,  progress  review  meetings.  The  project  review  meetings  shall  nominally  be 
held  on  a  weekly  basis,  but  no  less  frequently  than  biweekly,  with  major  contributors  to  the  benchmark  ex¬ 
ecution  summarizing  the  focus  of  their  work  over  the  prior  week.  The  size  of  the  benchmark  execution  team 
and  the  scope  of  the  benchmarks  is  anticipated  to  be  small  enough  that  weekly  meetings  will  require  only 
1-2  hours  to  complete.  The  main  purpose  of  these  meetings  is  to  maintain  a  ranning  account  of  progress  on 
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the  benchmark,  including  milestones,  problems,  schedule  changes,  etc.  Ideally,  the  weekly  or  biweekly 
meetings  will  be  held  in  connection  with  normal  project  management  meetings,  rather  than  becoming  an 
additional  set  of  meetings.  RASSP  program  meetings  and  reviews,  including  Benchmark  milestone  re¬ 
views,  may  be  substituted  for  the  benchmark  meetings  by  mutual  agreement  between  the  Developer  and  the 
Benchmarker.  At  the  time  of  each  progress  review  meeting,  electronic  activity  logs  of  personnel  involved 
in  the  benchmark  will  be  transmitted  to  Lincoln  Laboratory.  The  format  of  the  logs  will  include  the  individ¬ 
ual’s  name,  user  ID  and  breakdown  of  activity  by  task  and  tool  use.  The  log  should  include  summary  infor¬ 
mation  on  problems  with  RASSP  tools  or  processes  during  the  week,  and  an  indication  of  the  approximate 
time  (-  .5  hour  resolution)  devoted  to  each  task. 

All  person-hours  expended  on  the  benchmark  execution  must  be  reported  and  associated  with  tasks 
in  the  WBS.  The  reporting  must  be  sufficiently  detailed  to  distinguish  between  in-cycle  and  out-cycle  activ¬ 
ities.  The  desired  precision  of  task  time  reporting  is  .5  hours. 

In  order  to  support  geographically  distributed  benchmarking,  the  Developers  shall  be  required  to  sup¬ 
port  teleconference  and  video  conference  meetings  on  a  regular  basis. 
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6.  DEVELOPER  RESPONSE 


This  section  provides  additional  detail  regarding  the  response  the  Developer  shall  provide  to  BTD-2. 

6.1  BENCHMARK  EXECUTION  CHECK  LIST 

For  Benchmark-2,  the  Developer  shall  include  in  the  response  to  the  BTD  a  Benchmark  Execution 
Check  List  (BECL).  The  BECL  shall  be  based  on  the  RASSP  process  steps  which  the  Developer  envisions 

applying  to  execute  the  benchmark.  For  each  major  process  step,  the  Developer  shall  provide  the  followin^^ 
uiformation;  ® 

1.  Cost 

2.  Schedule 

3.  Tools  utilized 

4.  Caliber  of  individual(s)  required  to  execute  the  process 

The  BECL  can  also  be  organized  according  to  the  deliverables  (products)  required  in  BID-2,  but  in  this 
case,  the  process  steps  and  cost  associated  with  the  development  of  each  deliverable  must  be  indicated 
where  appropriate.  For  example,  since  application  hardware  and  software  are  deliverables,  the  process 
steps  and  tools  used  to  produce  the  hardware  and  software  must  be  indicated.  In  the  case  of  metric  deliver¬ 
ables,  the  costs  should  be  broken  out  on  the  basis  of  the  metric  categories  defined  in  Table  28  through 
Table  40. 

The  BTD  includes  points  of  contact  at  the  Benchmarker’s  organization  for  the  purpose  of  addressing 
technical  questions  regarding  the  BTD,  however,  all  questions  submitted  to  the  Benchmarker  shall  also  be 
submitted  simultaneously  to  the  cognizant  Government  COTR  or  his  designee. 

The  Developer  shall  respond  with  a  comprehensive  estimate  of  the  cost  to  execute  BTD-2  for  three 
processor  implementations  (see  Section  5.1.1).  For  the  “three-polarization”  implementation,  the  Developer 
shall  include  a  WBS  and  associated  schedule  for  the  tasks  in  the  WBS,  along  with  a  list  of  all  the  individuals 
assigned  to  work  on  the  Benchmark  more  than  an  average  of  one  day  a  week.  The  level  of  detail  shown  in 
the  WBS  and  schedule  shall  be  sufficient  to  identify  and  briefly  describe  the  distinct  steps  in  the  Developer’s 
RASSP  design  process,  and  shall  conform  to  specific  formats  and  reporting  details  called  for  in  this  BTD. 
For  each  entiy  m  the  BECL,  the  total  estimated  cost  of  executing  that  part  of  the  RASSP  process  shall  be 
requured.  An  indication  shall  be  provided  of  the  cost  and  schedule  impact  on  the  remaining  process  steps  of 
deleting  a  particular  process  step.  The  categories  of  impact  are: 

•  None 

•  Modest 
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•  Significant 

•  Essential 

For  the  “single-polarization”  and  “maximum  functionality  for  $500K”  processor  implementations,  WBS 
and  schedule  information  shall  be  given  as  deviations  (i.e.  “deltas”)  from  the  “three-polarization”  imple¬ 
mentation. 

The  Developer  response  to  the  BTD-2  shall  include  identification  of  procurement  risks  and  fall-back 
plans  in  the  event  items  can  not  be  procured. 

The  Developer  shall  provide  cost  estimates  including  life  cycle  costs  for  all  proposed  hardware  and 
software.  All  cost  estimates  must  provide  appropriate  background  information  for  review.  An  identifiable 
database  of  information  which  is  consistent,  accurate,  traceable  and  relevant  must  be  used  as  a  basis  for  the 
cost  estimate.  Appropriate  and  supportable  adjustments  can  be  made  to  the  database  as  required.  Factors 
such  as  inflation,  production  rate,  quantity  and  required  changes  must  be  considered.  Historical  data  may 
consist  of  hours  for  a  similar  completed  task  or  task  in  progress,  previous  material  or  subcontract  costs,  de¬ 
partmental  statistics  and  learning  curve  experience.  The  database  need  not  be  generally  accessible  to  per¬ 
sonnel  who  are  not  developer  employees,  but  all  estimates  must  be  auditable  (even  if  such  an  audit  must  be 
performed  by  DPRO).  A  suitably  calibrated  parametric  cost  estimate  is  considered  a  valid  substitute  for  a 
detailed  bottom-up  approach.  The  Developer  must  use  whatever  approach  is  deemed  appropriate  for  the  fu¬ 
ture  RASSP  design  environment.  In  the  event  the  benchmark  execution  is  distributed  over  more  than  one 
organization,  the  division  of  responsibility  should  be  clearly  indicated  as  part  of  the  BECL. 

6.2  TOOL  STATUS  INFORMATION 

At  the  outset  of  Benchmark-2,  along  with  the  schedule  and  cost  estimate,  the  Developer  shall  provide 
a  list  of  all  of  the  electronic  design  automation  (EDA)  tools  available  in  the  RASSP  system,  an  indication 
of  which  tools  are  likely  to  be  used,  and  a  description  of  the  RASSP  design  process  supported  by  the  tools. 
The  tool  and  process  description  shall  include,  as  a  minimum,  the  following  information,  and  shall  be  pro¬ 
vided  in  written  form  and  in  one  of  the  electronic  formats  described  in  Section  5: 

•  The  association  between  the  tools  and  the  RASSP  process  steps 

•  The  integration  status  of  each  tool  including: 

Revision  number  of  the  tool 

Interfaces  to  other  tools 

Level  of  integration  as  described  in  Section  6.3 

•  Minimum  host  machine  resources  required  to  effectively  use  each  tool  including: 

Minimum  host  memoiy  configuration  for  executable 

Disk  resources  required 

Representation  of  the  minimum  acceptable  CPU  performance  (e.g.  Specmarks) 
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Platforms  on  which  each  tool  is  supported 
Purchase  and  maintenance  costs  for  each  tool 

The  minimum  skill  category  or  area  of  specialization  required  to  effectively  use  each  tool. 
Example  tool  and  skill  categories  are  given  below: 


TOOL 

Word  Processor 
Architecture  Trade-off 
Ada  Compiler 
Thermal  Design 
VHDL  Simulator 
Schematic  Entry 


SKILL  CATEGORY 

Secretary/Technical  Writer 
System  Analyst 
Programmer 
Mechanical  Engineer 
Digital  Designer 
Technician 


In  order  to  visualize  the  degree  of  tool  integration  within  the  RASSP  design  environment,  the  equiv¬ 
alent  of  a  2-D  matrix  (N^  chart)  of  the  available  tools  will  be  created  and  the  level  of  integration  which  exists 
between  all  pairwise  combinations  of  tools  will  be  entered  as  a  number  at  the  row  and  column  intersection 
of  the  tool  pair.  The  level  of  tool  integration  shall  be  supplied  by  the  Developers  and  verified  by  the  Bench- 
marker. 


6.3  BENCHMARK  PERSONNEL  REPORTING 

A  list  of  all  the  individuals  projected  to  work  on  Benchmark-2  an  average  of  one  or  more  days  a  week 
must  be  provided  at  the  initiation  of  a  benchmark.  The  list  should  indicate  the  title  and  job  category  of  each 
of  the  individuals,  along  with  a  description  of  their  familiarity  with  both  the  benchmark  application  and  the 
RASSP  tools  and  processes.  Personnel  changes  made  during  the  course  of  the  benchmarking  by  the  Devel¬ 
oper  shall  be  reported  to  the  Benchmarker  at  the  time  the  changes  are  made. 
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APPENDIX  A 

CONVOLUTION  KERNELS 


Expressions  used  for  determining  the  convolution  kernels  can  be  developed  by  considering  the  com¬ 
plex  received  LFM  (linear  frequency  modulation)  signal  transmitted  at  time  tj  and  received  at  time  t, 

■s  (r)  -  Ae  , 

where  fg  is  the  transmit  center  frequency  (in  Hz),  A  is  the  signal  magnitude,  K  is  the  LEM  slope  (in  Hz  per 
sec),  and  is  the  round-trip  propagation  time  to  the  target.  The  de-ramp  signal  for  s(t)  is  given  by, 

+7zK(!-t.-zy] 

^  (A.2) 

where  is  the  round-trip  propagation  time  for  a  target  at  a  reference  range  Rq, 


X 


C 


The  resulting  de-ramped  received  pulse  is  given  by. 


(A.3) 


x(t)  =  s(t)d(t)  =  , 

where. 


(A.4) 


(j)(0  =  nK[Tf-T/-2(x^-T^)  (t-t.)]  -2jt/o(x^-xp  .  (A.5) 

In  range  compression,  x(t)  is  weighted  and  sampled  at  time, 

r  =  r.  +  x^  +  r5[«-/7x] ,  (A.6) 

where 

n  =  0,...,N-l,  (A.7) 

Tg  is  the  sampling  interval,  and  N  is  the  total  number  of  range  samples.  The  weighted  and  sampled  version 
of  x(t)  is  given  by. 


y(n)  =  W(n-m)x(/i)  =  W(n-mXBe''^^”^ 

where. 


(A.8) 


^(n)  =  7ti<r[(x^-xp^-2(x^-xp 


(n-m)T^]  -2nfQ(x^-'cJ 


(A.9) 
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and  W(n-m)  is  a  real- valued  weighting  function  symmetric  about  n=m.  The  range-compressed  pulses  are 
computed  as  the  DFT  of  y(n)  with  zero-padding,  so  that  a  compressed  pulse  is  given  by 

-jlnKTJz  -x  )  (n-m) 

DFT{y(n)}  =  DFT{W(n-m)e  }x 


j[KK(x^-  T^)  ^  -  2nfo  -  x^)  ] 

xBe 


(A.  10) 


Moreover, 


DFT{W{n-m) 


-j2nKT^(x^-x^)  (n-m) 
e 


■  -j2%KT^(x  -x  )n 

}  =  DFT{W{,n)e  }  x 


j2%  {mi/ N) 

X  ^  , 


(A.11) 


where  i  is  the  sample  in  the  transform  domain.  Because  W  (n)  exp  [-jr27C^rr^  (x^  -  x^)  n]  is  a  conju¬ 
gate-symmetric  function  of  n,  its  DFT  is  real-valued.  The  phase  term,  exp  [j2ji  (mi/N)  ]  ,  is  constant 
for  all  pulses.  For  the  case  of  m=N/2,  the  phase  term  reduces  to  (-1)'.  As  a  result,  the  phase  of  the  com¬ 
pressed  pulse,  3> ,  is  given  by  the  right-most  exponential  in  (A.IO), 

«I>(n)  =  7t/s:(X^-X^)^-27C/o(X^-X^)  .  (A.12) 

The  convolution  kernels  for  azimuth  compression,  exp  ^  are  formed  on  the  basis  of 

(A.12).  The  Aux  variable  SLTRNG  gives  the  slant  range  to  the  center  of  the  first  frame  of  the  pass,  Rq- 
Reference  ranges  for  the  31  kernels  are  those  between  the  ranges  of 

=  RQ-15.5^f^  (A.13) 

and 

rQ  =  RQ+U.5d^  (A.14) 

at  a  range  interval  of  dp  where  dj.  is  1/16*  the  length  of  the  range  window.  The  length  of  the  current  range 
window  is  468.4  m,  so  that  dj^29.3  m.  As  a  result,  16  kernels  are  needed  to  process  all  2048  range-gates  of 
the  processing  array  and  each  kernel  is  used  for  128  contiguous  range-gates.  The  kernels  used  for  a  partic¬ 
ular  processing  array  are  determined  from  the  center  range  of  the  input  frame  to  the  array,  R,  where  R 
comes  from  the  Aux  variable  SLTRNG.  That  is,  the  16  convolution  kernels  are  used  whose  reference  range 
lies  between 


=  Rq  + 


-1.5 -INT 


R^-R 


and 


(A.15) 
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(A.16) 


( 


''O  =  -^0  + 


1.5-INT 


R^-Rl 


r  AJ 


inclusive,  where  INT  [  ]  indicates  the  nearest  integer.  A  frame  having  R=Ro  would  use  16  convolution 
kernels  whose  reference  range  lies  between  Rq  -  7.5dr  and  Rq  +  7.5dp  inclusive. 

In  evaluating  (A.  12)  for  a  particular  convolution  kernel,  we  note  that  changes  from  PRI-to-PRI 
but  does  not.  Consider  a  constant  velocity  SAR  platform  that  transmits  a  pulse  at  a  constant  spatial 
interval  d^;  recall  that  dx=0.2287  m  for  the  current  system.  If  at  the  PRI  where  the  target  is  broad¬ 

side  to  the  SAR  platform,  the  range  to  the  target  at  any  other  PRI  is  approximately, 

{kd 

=  ro  -h  (A.17) 

where  k  is  the  (integer  number)  difference  between  the  PRI  being  processed  and  the  PRI  of  target-broad- 
side.  As  a  result,  x^  is  approximated  by. 


{kdf- 

UJ 

''o  2r 

L  ^^0  J 

(A.  18) 


The  phase  of  the  convolution  kernel  is  the  complex  conjugate  of  <I> ,  so  that  the  kernel  is  given  by, 

^^CONV  -7<E> 

«  =  e  (A.  19) 

where  O  is  given  by  (A.  12),  and  x^  and  x^  are  given  by  (A.3)  and  (A.  18),  respectively.  The  convolution 
kernel  (i.e.,  ^  QQj^jy')  nnust  be  calculated  for  all  pulses  within  the  length  of  the  synthetic  aperture,  where 


APERTURE  LENGTH  =  (A.20) 

At  a  center  frequency  f^  =  33.56  GHz,  a  resolution  of  RES  =  0.3  m  and  a  range  of  rp  =  7.26  km  yields  an 
aperture  length  of  108.09  m.  Because  d^  =  0.2287  m,  the  minimum  number  of  pulses  in  the  convolution 
kernel  is  473.  Currently,  512  pulses  are  used  in  calculating  the  convolution  kernels. 
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APPENDIX  B 

FIBER  OPTIC  MODULE 


TriQuint 

SEMICONDUCTOR 


Hot  Rod™ 

Rber  Optic  Cards  -  Short  Wavelength 
HRC->200FS,  HRC-500FS,  and  HRC-aOOFS 


General  Description 

The  HRC-200FS.  HR0500FS  and  HKC-800FS  fiber-optic  Hot 
Rod  cards  provide  a  oompiete  bidnecbonaJ  rxxle  tor  transmittirg 
arxi  receiving  40- bit  parallel  data  words  across  fiber-optic  media 
at  maximum  rates  of200. 500.  and 800  Mbrts/sec.  (250. 625.  and 
1000  MBaud).  These  cards  are  ideal  for  use  in  highpedonnarx* 
systems  where  data  communications  is  the  bottleneck  to  system 
performance. 

The  interface  to  the  Hot  Rod  card  is  designed  for  flexibitity.  The 
convenient  1 20- pin  high-density  connector  offers  a  small  physical 
tmertace.  The  transmiiler  artd  receiver  sections  have  separate 
data  and  control  signals.  Stowing  them  to  operate  snnuttaneousty 
and  independently.  Only  a  single  ♦SV  power  supply  is  required. 
Several  user  options  alow  tor  a  broad  range  of  operation.  Data 
transmission  can  be  selected  to  be 200. 400.  or 800 Mbits/sec.  for 
the  HRC-BOOFS.  250  and  500  Mbits/sea  tor  the  HRC-SOOFS, 
and  200  Mbits/sec  tor  the  HRC-200FS.  The  ondoard  optical 
data  links  transmi  t  arto  receive  data  across  rmjtti-mode  fiber-optic 
medja.  The  optics  on  the  cards  are  designed  using  shor. 
wavelength  CD  laser  technology. 

The  Hot  Rod  card  is  an  exceUent  vehide  tor  all  stages  of 
devetopmem.  Because  it  isacomplcto  solution,  it  can  shorten  the 
design  cycle  considerably  during  prototyping.  Its  compact  size 
and  proven  design  make  it  an  excellent  production  solution. 

Typical  Applications 

•  High-speed  netyifonts 

•  Poirrt-to-poin!  communications 


•  Bus  extenders 

•  High-bandwidth  digital  video  transmission 

Features 

•  Complete  fiber-optic  communicatk»is  node 
—  Hot  Rod  transmitter 

—  Hot  Rod  receiver 
—  On-board  Optical  Data  Links 
—  CD  laser  technology 

—  TrarKmrtartd  receive  up  to  300  meters  at  800  Mbits/sec. 
— Transmit  and  receive  up  to  1 000  meters  at  500  Mbrts/sec. 

•  Selectable  data  rates: 

—  Speeds  of  200. 400.  800  Mbrts/sec.  ter  HRC-800FS 
—  Speeds  of  250. 500  Mbits/sec.  tor  HRC-SOOFS 

•  Multi-mode  (50/125  or62.S/125)  fiber  compatibility 

•  Compatibte  with  32-t)il  microprocessor  systems 
— 40-bit  TTL  input  (transmit)  bus 

— 40-bit  TTL  output  (receive)  bus 

•  Loopback  diagnostic  capability 

•  Smgle  -tSV  supply 

•  Operable  with  the  Hot  Rod  Oevelopmont  System  (HRDS) 

•  Bit  Error  Rate  (BER)  <  lO*’^ 

•  Link  status  monitoring  capability 

•  120-pin  high-donsJtycoonoctor 

•  ST-typo  fiber-optic  connectors 

•  CofTpact  size  (approximaieiy  3’/«’  x  5") 
i  •  Commercial  temperature  range 


Block  Diagram 


rber-optk: 

WPUT 


TxSTRB 

TxACK 

TxOATA 

(0.JJ9) 

REFCLK 

TxLOOPEM 

RxLOOPEN 

DIVIXWVO 

RxSTRB 

RxDATA 

(0..39) 


TQS  Computing  and  Networking  Divisioo  •  2300  Owen  Street  •  Santa  Clara.  CA  95054-*  (408)  982-0900  •  FAX  (408)  982-0222 
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TriQuht^ 

SEMCONDUCrOR 


Operating  Modes 

The  HRC-JcxxFS  fiber-cptic  Hot  Rod  cards  can  operate  in  three 
modes:  oivboard  loopback,  liber  loopback,  and  startdard  fiber. 
These  are  outlinad  below. 


OwBoard  Loopback  Mode 
NO  CONNECT 


NO  CONNECT 

The  HRC-xxxFSHot  Rod  car*  may  be  operated  without  any  fiber 
connection.  By  asserting  both  LOOPEN  signals  HIGH,  the 
transmitter  device  will  wnte  directly  to  the  local  receiver  device. 
This  diagnostic  capability  is  a  useful  powernup  and  first  test 
exercise. 


Fibe  r  Loopback  UocSe 


OneHotRodcardsscapabteoftesbngvanousfibeis.  As  in  Mode 
1  above,  the  transmitter  sends  to  the  local  receiver.  In  this  case, 
however,  the  signal  rs  carried  through  a  fiber  that  has  been 
connected  from  ttie  fransmit  Bnk  to  the  receive  link. 

Standard  Fiber  Mode 


TO  target 
HOT  ROD  CARO 


FROM  TARGET 
HOT  BOO  CARD 

The  HROxxxFS  can  also  be  used  as  a  bidirectional  fiberoptic 
communications  node.  The  transmit  link  is  cocmected  (via  fiber) 
to  a  target  Hot  Rod  card.  Smilatrty.daa  is  recerved  from  a  target 
Hot  Rod  card. 


Data  Rates 

The  user  data  rale  is  selected  using  the  frequency  ol  the  reference 
Clock  (REFCLK)  and  the  value  ol  the  0IV1  arid  DIVO  input  control 
signals.  The  Hot  Rod  devices  are  speerfieti  to  run  with  a  REFCLK 
of  20  MHz  and  25  MHz,  The  word  rate  can  then  be  divided  down 
{by  a  factor  ol  2  or  4).  using  toe  Dl V  signals  as  indicated  in  the  table 
below. 

The  F^FCLK  is  an  external  TTL-compaable  signal  which  is  input 
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HRC.200FS,  HRC-500FS,  HRC-800FS 


through  the  conneaor.  This  sigml  must  be  within  the  limits 
detailed  m  the  AC  Specifications  of  the  Hot  Rod  device  data  sheet. 
The  vanous  allowable  frequencies  arxj  configurations  are: 


DIV1  DIV  0  WORD  RATE  |  BIT  RATE  REFCLK 
_ (Wworcte/sac.)  |  (Mbits/gec)  (MHz) 

1  I  t  20  I  800  20 


Non;Tli«s«ofOth«ony  vtWconngcftbORSlcxiho  HnC-»aFS  Hot  Rod  amt. 


Optical  SpecHicatBons  (Tmnp  »  o-ctrc} 

I  [TRANSMITTER  RECOVER  | 


MIN 

MAX 

MIN 

MAX 

UNITS 

Center  Wavelength 

830 

870 

— 

nm 

Spectra  Width 

— 

15 

— 

— 

nm 

Average  Power  | 

i  -3.5 

i  0 

0 

j  dBm 

Rise^aH  Time  j 

;  — 

i0.4-KB’ 

— 

0.5 

ns 

Extinction  Ratio 

:  5:1  1 

— 

— 

Note:  ’  B  =  Baud  Rate  =  1.25  x  Bit  Rate 
"  See  Max  Link  Loss  table  below 
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THQuint^ 

SEMICONDUCTOR  HR&.200FS,  HRC-500FS,  HRC*800FS 


Mechanical  Dimensions 


Edge  Connector  Specification 


Hot  Rod  Development  System 


In  ortJer  to  facilitate  evaluation  of  the  Hot  Rod  chipset.  Hot 
Rod  cards,  and  the  capabilities  of  various  fibers.  TriQuint 
offersihe  Hot  Rod  Development  System.  The  Devetapment 
System  HRDS-800FS,  for  example,  comes  with  the  HRC- 
80OFS  Hot  Rod  interface  card,  and  provides  a  variety  of 
capabHities,  from  test  pattern  ger^eration  to  Bit  Error  Rate 
counting  and  automatic  togging  of  test  results.  The 
Development  System  hncJudes  EPROM-based,  menu- 
driven  software  for  running  many  different  tests,  and  it  may 
also  be  user-programmed  for  special  appticatioris. 


Power  Supply  Specifications 


The  boaitt  should  be  supplied  by  a  higtvqiiaiity. 
computer-grade  power  supply  capable  of  at  least  1 .5  A 
at  -t^S  V  (4.75V  min.,  5.25  V  max.). 


7x02 

C  61  lO 

7x02 

C  62  20 

7x06 

C  63  30 

7x07 

C  6«  40 

7x010 

C  65  50 

7x011 

C  66  60 

7x014 

C  67  7C 

7x015 

C  68  80 

7x018 

C  69  90 

7xD19 

O  70  lOO 

7x022 

0  71  11 0 

7x023 

Q  72  120 

GND 

O  73  130 

GNO 

O  74  140 

7x026 

Ots  ISO 

7x027 

0  76  160 

7x030 

O  77  170 

7x031 

0  78  180 

7xPWR 

O  79  190 

7xPWR 

Oeo  2oC 

7x034 

0  81  21  o 

TxD3S 

082  220 

7x038 

0  83  230 

7x039 

0  84  240 

7xDlV1 

0  85  2S0 

7xDlV0 

086  260 

7xSlAVE 

087  270 

7xSTRB 

088  280 

GND 

089  29C 

GNO 

090  30C 

Rx2XCLK 

O  91  31  0 

RxIXOK 

Os2  32C 

reserved 

Q  93  330 

SIGDET 

O94  34C 

RxOlVI 

OgS  35C 

RxDlVO 

O96  360 

RxD2 

Og?  370 

RxD3 

=^9S  38C 

Rx06 

^99  390 

RxD7 

OIOO  400 

RxPWR 

OIOI  410 

RxPWR 

0  102  42  0 

RxDIO 

OlC3  430 

RxOn 

0  104  44  0 

RxOl4 

0105  450 

RxDIS 

OIO6  460 

GNO 

Ol07  470 

GND 

OIC8  480 

RxDie 

0109  490 

RiDIS 

Ci  no  500 

RxD22 

Cm  51  0 

RxD23 

0112  520 

Ri026 

0113  53O 

RxD27 

C  1 14  54  0 

RxD30 

0  115  sso 

Rx031 

One  560 

RxD34 

On?  57O 

RxD35 

O118  580 

RxD38 

0  119  59O 

Rx039 

0  120  60C 

TxDO 

TxOI 

TxD4 

TxDS 

TxD8 

Tx09 

TxDt2 

7x013 

7x016 

7x017  ■ 

7x020 

7x021 

CND 

GND 

7x024 

7x025 

7x028 

TxD29 

7xPWR 

RESERVED 


7x032 

7x033 

7x036 

7x037 

7xACK 

7XLOOPEN 

RxLOOPEN 

REFCLK 

7X1XCLX 

7x2XCLK 

GND 

GND 

RxSTRB 

RESERVED 

ftxSYNC 

RxERROR 

RxDO 

RxDl 

RxD4 

RxOS 

RxPWR 

RESERVED 

Rxoe 

RxD9 

Rx012 

RxD13 

GNO 

GNO 

Rxoie 

Rx017 

flxD20 

fl34)21 

Rx024 

RxD25 

RxD28 

RxD29 

RxD32 

Rx033 

RxD36 

RxD37 
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HRC-200FS,  HRC-500FS,  HRC-800FS 


Ordering  Information 


Safety  Procautiom 


DATA  RATE  (Mbttsfeec)  j 

200  1  250  1  400 

500  1  800 

KRC-SOOFS 

■vj — 

!  y 

HROSOOFS 

1  /  1  ^ 

/  i 

HRC-200FS 

_ ! _ 1 

1 

Handling  Precautions 


1.  Highetectf«*atic6ekteeanpeiTnanentty  (Jamagetfie 
device.  Norrrai  harxlting  precautioris  lor  electrostaiiC' 
sensitive  devices  stvxild  be  taken  (as  CMOS). 


2-  Sernicooductor  Jasers  are  easily  damaged  by  overloadtng 
or  by  current  surges.  Appropriate  transient  protection 
precautions  should  be  raken. 

TriQuin!  win  not  bs  SaWe  lor  any  carnages  arising  trom 
the  use  df  ms  Laser  DiodebaseC  prockc:. 


. . 


WARNMGI 
LASEP  RAOUTtON-THWOnleolnopmtktn 


wtikii  «My  tw  MnrM  to  liw  iHMMn 


Typical  Test  Results 


Board 
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GLOSSARY 


Application  Thread 

Benchmark  Cycle 

Benchmark  Technical  Description 

COCOMO 

Data  Source/Sink 

PRICE 

Scalability 

SEER 

Virtual  prototyping 


An  application  chosen  as  the  vehicle  for  one  or  more  six-month 
benchmark  execution  cycles.  The  first  series  of  benchmarks  is 
based  on  a  real-time  processor  for  synthetic  aperture  radar  imag¬ 
ing. 

A  nominal  six-month  long  period  during  which  the  Developer 
applies  the  current  RASSP  process  to  develop  an  application  and 
meet  the  requirements  defined  in  a  Benchmark  Technical 
Description. 

The  BTD  is  a  document  and  supporting  technical  information 
which  defines  each  benchmark  including  system  requirements, 
deliverables,  and  allowable  duration. 

A  well-documented  parametric  cost  estimation  tool  for  software 
efforts.  Many  computer  programs  which  implement  different  ver¬ 
sions  of  the  COCOMO  equations  are  available. 

The  Data  Source/Suik  is  a  VME-based  turn-key  system  which 
shall  be  delivered  to  the  Developer  by  the  Benchmarker  for  use  in 
supplying  real-time  data  to  RASSP  hardware  test  article,  and  cap¬ 
turing  real-time  data  produced  by  the  RASSP  hardware  test  arti¬ 
cle. 

A  suite  of  parametric  cost  estimation  computer  programs  from 
Martin  Marietta.  The  product  line  presently  covers  software  and 
software  life  cycle  (PRICE  S),  microcircuits  and  electronic 
assemblies  (PRICE  M),  hardware  systems  (PRICE  H)  and  hard¬ 
ware  life  cycle  (PRICE  HL). 

As  applied  to  hardware  and  software  architectures  is  the  property 
of  being  expandable  to  address  new  requirements  without  sub¬ 
stantially  changing  the  design  or  the  existing  components. 

A  suite  of  parametric  cost  estimation  computer  programs  from 
Galorath  Associates.  The  product  line  presently  consists  of  a  soft¬ 
ware  sizing  model  (SEER-SSM),  software  estimation  model 
(SEER-SEM),  integrated  circuit  model  (SEER-IC),  hardware 
estimation  model  (SEER-H)  and  hardware  life  cycle  model 
(SEER-HLC). 

The  process  of  simulating  all  applicable  levels  of  hardware  func¬ 
tionality  (whether  behavioral  or  register-transfer  level)  in  a  hard¬ 
ware  description  language  such  as  VHDL. 
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ACRONYMS 


A/D 

Analog  to  Digital  Converter 

ADTS 

Advanced  Detection  Technology  Sensor 

API 

Application  Programming  Interface 

ARCM 

Application  Requirement  Complexity  Metric 

ARPA 

Advanced  Research  Projects  Agency 

ASIC 

Application  Specific  Integrated  Circuit 

ATR 

Automatic  Target  Recognition 

BECL 

Benchmark  Execution  Check  List 

BTD 

Benchmark  Technical  Description 

COCOMO 

Constructive  Cost  Model 

COTS 

Commercial  Off-The-Shelf 

CSC 

Computer  Software  Component 

CSCI 

Computer  Software  Configuration  Item 

CSU 

Computer  Software  Unit 

DR 

Data  Fiber  Interface 

DPT 

Discrete  Fourier  Transform 

DSP 

Digital  Signal  Processor 

BBS 

Electronic  Breakdown  Structure 

EOF 

End  of  File 

FFT 

Fast  Fourier  Transform 

FIR 

Finite  Impulse  Response 

FPGA 

Field-Programmable  Gate  Array 

GOPS 

Giga-Operations  per  Second 

GPS 

Global  Positioning  System 

GUI 

Graphical  User  Interface 

HCM 

Hardware  Complexity  Metric 

HDL 

Hardware  Definition  Language 

HOL 

Higher  Order  Language 

IF 

Intermediate  Frequency 

IMU 

Inertial  Measurement  Unit 

INU 

Inertial  Navigation  Unit 

I/Q 

In-phase  and  Quadrature 
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LFM 

Linear  Frequency  Modulation 

LL 

Lincoln  Laboratory 

LRU 

Line  Replacement  Unit 

LSB 

Least  Significant  Bit 

Mbps 

Megabits  per  second 

MB 

Megabyte 

MCM 

Multi-Chip  Module 

MDL 

Metric  Deliverable  List 

MFLOPS 

Millions  of  Floating  Point  Operations  per  Second 

MIPS 

Millions  of  Instructions  per  Second 

MOPS 

Millions  of  Operations  per  Second 

MSB 

Most  Significant  Bit 

MW 

Megaword 

PAL 

Programmable  Array  Logic 

PCB 

Printed  Circuit  Board 

PLD 

Programmable  Logic  Device 

PME 

Prime  Mission  Equipment 

PRF 

Pulse  Repetition  Frequency 

PRI 

Pulse  Repetition  Interval 

PRICE 

Parametric  Review  of  Information  for  Costing  and  Evaluation 

PSE 

Peculiar  Support  Equipment 

r4 

Range  to  the  fourth  power 

RAID 

Redundant  Array  of  Independent  Disks 

RASSP 

Rapid  Prototyping  Application-Specific  Signal  Processors 

RCS 

Radar  Cross  Section 

REVIC 

Revised  Intermediate  COCOMO 

SAR 

Synthetic  Aperture  Radar 

SEER 

System  Evaluation  and  Estimation  of  Resources 

SEI 

Software  Engineering  Institute 

SEM-E 

Standard  Electronic  Module,  Format  E 

SNR 

Signal-to-Noise  Ratio 

UAV 

Unmaimed  Air  Vehicle 

VME 

Versa  Module  Europe 

WBS 

Work  Breakdown  Structure 
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